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
actually
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
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 fine. Could
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.
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
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 Dutch
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,
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
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
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.03879 0.03783
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
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
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 for
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 (...).
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:01.810
filter
Hi,
Got one question:
reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449
( http://nmi.nl/index.php?pageId=1215lg=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 NTP source need to set
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=1215lg=nl )
A wireshark capture shows that it sends a bogu reftime ...
Reference Clock Update Time: Jan 5, 2009
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 time since
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 last a valid
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,
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
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=1215lg=nl )
A wireshark capture shows that it sends a bogu reftime ...
Reference
David Woolley da...@ex.djwhome.demon.co.uk.invalid 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
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 refuses
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 the regular
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
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 ntpdate
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 to
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 regular ntp
29 matches
Mail list logo
