David Woolley wrote:
> Heiko Gerstung wrote:
>
>> In the NTPv4 draft you will find a (similar) definition: Root dispersion
>> indicates the maximum error, that does not necessarily mean that this is
>> the current error.
>
> And maximum error means theoretical worst case, not that this value has
Heiko Gerstung wrote:
> In the NTPv4 draft you will find a (similar) definition: Root dispersion
> indicates the maximum error, that does not necessarily mean that this is
> the current error.
And maximum error means theoretical worst case, not that this value has
actually been reached at any
Yes: got a mail from the mail responsible for the system.
He told me that he manually disconnected the IRIG-B connection to the
NTP server hardware. Then after resetting the time the server told him
that it is locked to PPS. <- more or less translated what he told me.
On Mon, Jan 12, 2009 at 10:5
They must have changed something!
Their refid now reads PPS and the offset is much more reasonable:
> remote refid st t when poll reach delay offset jitter
> ==
> -ntp2.inrim.it .UTCI.
Folkert van Heusden schrieb:
>>> It seems the Dutch NMi organisation (which is the time reference for the
>>> Netherlands) has an NTP-service as well. Now I tried retrieving the time
>>> with ntpdate (just to see if it was reachable) but ntpdate refuses it.
>>> Using the regular ntp daemon works fi
Terje Mathisen wrote:
>
> Assuming the clock itself is OK, then I believe the problem might be
> with their dispersion calculation, i.e. the dispersion value will be
> assumed to increase linearly from the time of the last sync to a better
> (lower stratum) reference clock.
Root dispersion ca
Unruh wrote:
>
> No, it was last synchronized from IRIG then. Since then it is supposed to
> have been synchronized from the H masers they keep as a primary world time
> source for Neatherland's UTC time source. I assume this is being done by
If they are only synchronising to IRIG every 3+ days
Folkert van Heusden wrote:
>>> Does a valid NTP source need to set the reftime to something valid?
>>> Does the ntp spec say so?
>> I can't tell you that, Folkert, but, in your particular environment, would
>> /you/ trust a NTP source which was last synched 3 days ago?
>
> Well, they (NMi) are the
David Woolley writes:
>Folkert van Heusden wrote:
>>
>> Ok so the root dispersion is not too high if I understand you correctly
>> (well it would be better if it were lower)
>The root dispersion is consistent with having a very old reference time.
> The reference time is too old, which means
hun...@comcast.net (Rob Neal) writes:
>On Fri, 9 Jan 2009, Folkert van Heusden wrote:
>> Hi,
>>
>> Got one question:
>>
>>> reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449
>>> ( http://nmi.nl/index.php?pageId=1215&lg=nl )
>> A wireshark capture shows that it sends
Folkert van Heusden wrote:
>
> Ok so the root dispersion is not too high if I understand you correctly
> (well it would be better if it were lower)
The root dispersion is consistent with having a very old reference time.
The reference time is too old, which means the root dispersion is too
hi
> The reason that I keep on going on this system is that I would like to
> have them get it to also work with ntpdate and such and not only the
> windows implementation. The reasons for them to fix it I come up with is
> now:
> - root dispersion too high
> - offset too high; 52ms (tried from ADSL,
> >>> The Root dispersion does not look too healthy, too...
> >>> Root Dispersion:3,9689 sec
> >
> > The root dispersion, that is the amount of time this server is
> > behind/faster than the stratum 0 device? So optimally that should be 0?
>
> No. It is 15 times the time since there was
Folkert van Heusden wrote:
>>>
>>> The Root dispersion does not look too healthy, too...
>>> Root Dispersion:3,9689 sec
>
> The root dispersion, that is the amount of time this server is
> behind/faster than the stratum 0 device? So optimally that should be 0?
No. It is 15 times the tim
folk...@vanheusden.com (Folkert van Heusden) writes:
>Hi,
>Got one question:
>> reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449
>> ( http://nmi.nl/index.php?pageId=1215&lg=nl )
> A wireshark capture shows that it sends a bogu reftime ...
> Reference Clock Upda
On Fri, 9 Jan 2009, Folkert van Heusden wrote:
> Hi,
>
> Got one question:
>
>> reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449
>> ( http://nmi.nl/index.php?pageId=1215&lg=nl )
> A wireshark capture shows that it sends a bogu reftime ...
> Reference Clock Upda
Hi,
Got one question:
> reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449
> ( http://nmi.nl/index.php?pageId=1215&lg=nl )
A wireshark capture shows that it sends a bogu reftime ...
Reference Clock Update Time: Jan 5, 2009 08:45:47,4493 UTC
>>
>> Does a valid N
On Fri, 9 Jan 2009, Folkert van Heusden wrote:
transmitted 4, in filter 4
reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449
originate timestamp: cd0f5b7d.d6ff250b Wed, Jan 7 2009 17:49:01.839
transmit timestamp: cd0f5b7d.cf7e90ff Wed, Jan 7 2009 17:49:0
Folkert van Heusden wrote:
[]
> Well, they (NMi) are the Dutch national organisation for standards.
> This time ought to be no more than micro (nano?) seconds from UTC.
> What the guy from NMi tells me is that they synced the time a couple
> of days ago and then hooked it up to their 4 cesium clock
> > I can't tell you that, Folkert, but, in your particular environment,
> > would /you/ trust a NTP source which was last synched 3 days ago?
>
> It is quite unclear what the purpose of this server is. The only
> documented use case (through their web site) is syncing Windows XP
> workstations (
> > Does a valid NTP source need to set the reftime to something valid?
> > Does the ntp spec say so?
>
> I can't tell you that, Folkert, but, in your particular environment, would
> /you/ trust a NTP source which was last synched 3 days ago?
Well, they (NMi) are the Dutch national organisation
David J Taylor schreef:
> I can't tell you that, Folkert, but, in your particular environment,
> would /you/ trust a NTP source which was last synched 3 days ago?
It is quite unclear what the purpose of this server is. The only
documented use case (through their web site) is syncing Windows XP
w
Folkert van Heusden wrote:
[]
> Does a valid NTP source need to set the reftime to something valid?
> Does the ntp spec say so?
I can't tell you that, Folkert, but, in your particular environment, would
/you/ trust a NTP source which was last synched 3 days ago?
David
_
> >> transmitted 4, in filter 4
> >> reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449
> >> originate timestamp: cd0f5b7d.d6ff250b Wed, Jan 7 2009 17:49:01.839
> >> transmit timestamp: cd0f5b7d.cf7e90ff Wed, Jan 7 2009 17:49:01.810
> >> filter delay: 0.03938 0.03787 0.0387
Folkert van Heusden schreef:
> Got this morning an e-mail from NMi and what they say is that they only
> occasionally connect their ntp server to a source that says what time it
> is. They had it connected to that irig-b because of the leapsecond and
> disconnected it at January 5. The rest of the
> > It seems the Dutch NMi organisation (which is the time reference for the
> > Netherlands) has an NTP-service as well. Now I tried retrieving the time
> > with ntpdate (just to see if it was reachable) but ntpdate refuses it.
> > Using the regular ntp daemon works fine. Could someone enlighten m
Heiko Gerstung wrote:
> Folkert van Heusden schrieb:
>> Hi,
>>
>> It seems the Dutch NMi organisation (which is the time reference for the
>> Netherlands) has an NTP-service as well. Now I tried retrieving the time
>> with ntpdate (just to see if it was reachable) but ntpdate refuses it.
>> Using t
On Thu, 8 Jan 2009, Heiko Gerstung wrote:
> Folkert van Heusden schrieb:
>> Hi,
>>
>> It seems the Dutch NMi organisation (which is the time reference for the
>> Netherlands) has an NTP-service as well. Now I tried retrieving the time
>> with ntpdate (just to see if it was reachable) but ntpdate
Folkert van Heusden schrieb:
> Hi,
>
> It seems the Dutch NMi organisation (which is the time reference for the
> Netherlands) has an NTP-service as well. Now I tried retrieving the time
> with ntpdate (just to see if it was reachable) but ntpdate refuses it.
> Using the regular ntp daemon works f
On Wed, 7 Jan 2009, Folkert van Heusden wrote:
> Hi,
>
> It seems the Dutch NMi organisation (which is the time reference for the
> Netherlands) has an NTP-service as well. Now I tried retrieving the time
> with ntpdate (just to see if it was reachable) but ntpdate refuses it.
> Using the regula
Hm, does not respond to ntpq -p so hard to see what it is reporting.
folk...@vanheusden.com (Folkert van Heusden) writes:
>Hi,
>It seems the Dutch NMi organisation (which is the time reference for the
>Netherlands) has an NTP-service as well. Now I tried retrieving the time
>with ntpdate (just
>>> In article <20090107165847.gm20...@vanheusden.com>, folk...@vanheusden.com
>>> (Folkert van Heusden) writes:
Folkert> Hi, It seems the Dutch NMi organisation (which is the time
Folkert> reference for the Netherlands) has an NTP-service as well. Now I
Folkert> tried retrieving the time with nt
Hi,
It seems the Dutch NMi organisation (which is the time reference for the
Netherlands) has an NTP-service as well. Now I tried retrieving the time
with ntpdate (just to see if it was reachable) but ntpdate refuses it.
Using the regular ntp daemon works fine. Could someone enlighten me why
it is
33 matches
Mail list logo