Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 been reached at any time. I think a basic question is: If the epoche (i.e. the correct time in this case) is set by some means (IRIG in this case) and time is continuously disciplined via a good PPS signal, should the returned reference timestamp continue be updated, and the root dispersion kept low in this case? If for some reason the absolute time on the server is not correct then an increasing root dispersion would not help anyway ... On the other hand, if the operators have the chance to keep the epoche synchronized via IRIG, why don't they just leave the IRIG signal connected? Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 time. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 someone enlighten me why it is refused? I mean: has gone too long without sync seems a little odd as it is supposed to be connected to real atomic clocks. ... reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449 ... A wireshark capture shows that it sends a bogu reftime ... Reference Clock Update Time: Jan 5, 2009 08:45:47,4493 UTC Originate Time Stamp: Jan 8, 2009 10:15:39,0507 UTC Receive Time Stamp: Jan 8, 2009 10:15:39,0375 UTC Transmit Time Stamp: Jan 8, 2009 10:15:39,0376 UTC The Root dispersion does not look too healthy, too... Root Dispersion:3,9689 sec This really looks like they should have a look at their NTP server and its IRIG source. Why this server is accepted by ntpd is a miracle for me. Only chance I would see is if you have no other sources configured. 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 time they only have it connected to the PPS source. But it seems that they are using something else than NTP to synchronize the time on their NTP server to this PPS signal, otherwise the RefID should say PPS but should be rejected because the the ToD source for this PPS reference is not synchronized anymore. That root dispersion, does that mean the time of that clock is almost 4 seconds behind the real time (the time of the IRIG)? From RFC1305: Root Dispersion (sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion): This is a signed fixed-point number indicating the maximum error relative to the primary reference source at the root of the synchronization subnet, in seconds. 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. As mentioned by other people, I would recommend to use the local clock if they use some none-ntp means to steer the clock of their NTP servers with their undoubtedly excellent PPS signal. But it is mandatory that they introduce some means to be able to stop claiming that they are stratum 1 when the PPS input fails. The preferred solution IMHO would be to permanently connect their IRIG source to the server and probably use the ATOM driver instead of mixing NTP and non-NTP references. Cheers, Heiko Folkert van Heusden ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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. 1 u 709 1024 377 25.2960.437 0.091 +ntp.nmi.nl .PPS.1 u 313 1024 3577.1280.146 0.039 *ntp1.nl.uu.net .PPS.1 u 645 1024 3774.6950.061 0.012 -auth1.xs4all.nl 193.79.237.142 u 697 1024 3774.575 -0.633 0.019 +ns1.tcd.ie 193.62.22.74 2 u 701 1024 377 22.632 -0.138 0.291 +ntp2.virtu.nl 193.67.79.2022 u 656 1024 3771.240 -0.120 0.046 N ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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:56:50AM +0100, Nero Imhard wrote: 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. 1 u 709 1024 377 25.2960.437 0.091 +ntp.nmi.nl .PPS.1 u 313 1024 3577.1280.146 0.039 *ntp1.nl.uu.net .PPS.1 u 645 1024 3774.6950.061 0.012 -auth1.xs4all.nl 193.79.237.142 u 697 1024 3774.575 -0.633 0.019 +ns1.tcd.ie 193.62.22.74 2 u 701 1024 377 22.632 -0.138 0.291 +ntp2.virtu.nl 193.67.79.2022 u 656 1024 3771.240 -0.120 0.046 N ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions Folkert van Heusden -- MultiTail är en flexibel redskap för att fälja logfilar, utför av commandoer, filtrera, ge färg, sammanfoga, o.s.v. följa. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 national organisation for standards. This time ought to be no more than micro (nano?) seconds from UTC. Absolute worst case should be something like 50 ns offset from the UTC assemble clock, more probably somewhere in the 1-10 ns range. (Do note that the real UTC clock doesn't exist, except as a paper number generated about a month after the fact: After comparing and weighing all the clocks that go into the official UTC assemble, each contributing clock (or national lab assemble of clocks) get back a number stating how far they were off.) 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 clocks. So in theory there shouldn't be any difference with UTC. See above. I'm bothering you people for this as I would like to get them to fix it. But for that I need to be able to give a explanation. 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. For a standards lab Cs clock, that dispersion value should be in the low ns range even after multiple days, and never get up to a single us, afaik. Terje -- - terje.mathi...@hda.hydro.com almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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, the root dispersion is correct, and 52ms is really quite a good actual accumulaed error (root dispersion is a pessimistically high value, assuming that the clock was originally properly synchronised, and there haven't been any anomalies of the sort associated with clock calibration on recent versions of Linux). something other than ntp (eg a separate oven controlled clock source driven by the world TAI standard)and thus ntp does not see it, and thinks that the last time the local clock was synchronized was a week ago, while actually the local clock is continually synchronized to far far better than ntp could ever hope to do it. But noone told ntp. If the local clock is being synchronised by means other than ntpd, you have the original, and most valid reason for using the local clock driver. The local clock driver's fault with root dispersion is that it actually gives a wildly optimistic value, by resetting it every poll interval, which then fails to reflect the actual error on an undisciplined local clock (you seem to be speculating on a disciplined, just not by ntpd, one). Basically, if the local clock is being synchronised directly, they should be running the local clock driver, as preferred, and with a low stratum (0 if they have some means of promptly shutting down if synchronisation fails). Generally, we are guessing at their real configuration, but either their configuration or ntpd is broken, as far as acting as NTP server is concerned. However, it is likely to still be acceptable to w32time, and if that is its intended purpose, it may well be OK, even if one would question a starndards organisation providing such a low quality service, even if the clients only need low quality. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 calculations don't extend back into the reference clock. For a standards lab Cs clock, that dispersion value should be in the low ns range even after multiple days, and never get up to a single us, afaik. That would imply they are using very special hardware, with the PC software clock motherboard crystal directly phase locked to the atomic clock. Assuming more conventional hardware, either they are not locked to PPS, or ntpd is ignoring the PPS signal in determining the reference time. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 refused? I mean: has gone too long without sync seems a little odd as it is supposed to be connected to real atomic clocks. ... reference time:cd0c473b.73087696 Mon, Jan 5 2009 9:45:47.449 ... A wireshark capture shows that it sends a bogu reftime ... Reference Clock Update Time: Jan 5, 2009 08:45:47,4493 UTC Originate Time Stamp: Jan 8, 2009 10:15:39,0507 UTC Receive Time Stamp: Jan 8, 2009 10:15:39,0375 UTC Transmit Time Stamp: Jan 8, 2009 10:15:39,0376 UTC The Root dispersion does not look too healthy, too... Root Dispersion:3,9689 sec This really looks like they should have a look at their NTP server and its IRIG source. Why this server is accepted by ntpd is a miracle for me. Only chance I would see is if you have no other sources configured. 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 time they only have it connected to the PPS source. That root dispersion, does that mean the time of that clock is almost 4 seconds behind the real time (the time of the IRIG)? Folkert van Heusden -- www.ishetweekend.nl -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 0.0 0.0 0.0 0.0 filter offset: 0.023514 0.023034 0.023029 0.023167 0.00 0.00 0.00 0.00 delay 0.03783, dispersion 0.00012 offset 0.023167 7 Jan 17:49:01 ntpdate[22293]: no server suitable for synchronization found ( 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 the reftime to something valid? Does the ntp spec say so? Originate Time Stamp: Jan 8, 2009 10:15:39,0507 UTC Receive Time Stamp: Jan 8, 2009 10:15:39,0375 UTC Transmit Time Stamp: Jan 8, 2009 10:15:39,0376 UTC 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? Is there a limit defined in the ntp spec? Folkert van Heusden -- Ever wonder what is out there? Any alien races? Then please support the s...@home project: setiathome.ssl.berkeley.edu -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 workstations (...). An actual access policy is nowehere to be found, and the time offset is quite large. I will try and see if I can find out more. N ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 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 clocks. So in theory there shouldn't be any difference with UTC. I'm bothering you people for this as I would like to get them to fix it. But for that I need to be able to give a explanation. Folkert van Heusden -- Multitail es una herramienta flexible que permite visualizar los log file y seguir la ejecución de comandos. Permite filtrar, añadir colores, combinar archivos, la visualización de diferencias (diff- view), etc. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 (...). An actual access policy is nowehere to be found, and the time offset is quite large. I will try and see if I can find out more. I think they're meant to give the standard time for the Netherlands: http://nmi.nl/index.php?pageId=231lg=nl says: The group of cesium clocks at NMi Van Swinden Laboratorium (VSL) provides the standard for frequency, time interval and the legal time in the Netherlands. NMi VSL calibrates frequency counters and frequency generators, oscilloscopes, stroboscopes and stopwatches, frequency, time interval, rise time and time base. NMi VSL also provides traceability to accredited laboratories through a Time Service Bulletin. Folkert van Heusden -- www.ishetweekend.nl -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 delay: 0.03938 0.03787 0.03879 0.03783 0.0 0.0 0.0 0.0 filter offset: 0.023514 0.023034 0.023029 0.023167 0.00 0.00 0.00 0.00 delay 0.03783, dispersion 0.00012 offset 0.023167 7 Jan 17:49:01 ntpdate[22293]: no server suitable for synchronization found ( 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 the reftime to something valid? Does the ntp spec say so? Yes. Quote 'Time when the system clock was last set or corrected, in NTP timestamp format' unquote. Originate Time Stamp: Jan 8, 2009 10:15:39,0507 UTC Receive Time Stamp: Jan 8, 2009 10:15:39,0375 UTC Transmit Time Stamp: Jan 8, 2009 10:15:39,0376 UTC 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? dispersion is part of the error statistics. See the spec, or better yet buy the book. See Chapter 11. Smaller is better, for obvious reasons, but it won't be zero. So optimally that should be 0? Is there a limit defined in the ntp spec? MAXDIST. 1 second in the reference implementation, which is a bit generous. Folkert van Heusden -- Ever wonder what is out there? Any alien races? Then please support the s...@home project: setiathome.ssl.berkeley.edu -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 the reftime to something valid? Does the ntp spec say so? Yes. Quote 'Time when the system clock was last set or corrected, in NTP timestamp format' unquote. So this can be years in the past? If so: why is ntpdate then refusing this server? Is it because of the huge root dispersion? Root Dispersion:3,9689 sec ... So optimally that should be 0? Is there a limit defined in the ntp spec? MAXDIST. 1 second in the reference implementation, which is a bit generous. like bigger than the 1 second in the ref.impl.? Folkert van Heusden -- Looking for a cheap but fast webhoster with an excellent helpdesk? http://keetweej.vanheusden.com/redir.php?id=1001 -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 08:45:47,4493 UTC Does a valid NTP source need to set the reftime to something valid? Does the ntp spec say so? Yes. Quote 'Time when the system clock was last set or corrected, in NTP timestamp format' unquote. So this can be years in the past? If so: why is ntpdate then refusing this server? Is it because of the huge root dispersion? Yes. You don't want to trust this time source. Use a pool server and move on. The folk providing this time source either don't understand how to operate a server or don't care enough to monitor its performance. Root Dispersion:3,9689 sec ... So optimally that should be 0? Is there a limit defined in the ntp spec? MAXDIST. 1 second in the reference implementation, which is a bit generous. like bigger than the 1 second in the ref.impl.? the spec and the reference implementation agree. Which is sorta the whole point of a reference implementation, IMHO. Folkert van Heusden -- Looking for a cheap but fast webhoster with an excellent helpdesk? http://keetweej.vanheusden.com/redir.php?id=1001 -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 there was last a valid reading from the reference clock. 4 seconds is about the 3 days you observe the reference time. There are other components, but this one will dominate here. 15ppm is a fairly pessimistic estimate of the residual frequency error in a server that has been synchronised in the past. I thought that ntpd was supposed to set stratum 16 if this value got too high. w32time doesn't, but this doesn't have the poor precision associated with w32time, and it looks like that in at least some circumstance, at least some versions of ntpd will report an excessive root distance without going to stratum 16. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 reading from the reference clock. 4 seconds is about the 3 days you observe the reference time. There are other components, but this one will dominate here. Ok so the root dispersion is not too high if I understand you correctly (well it would be better if it were lower) I thought that ntpd was supposed to set stratum 16 if this value got too high. The systems I checked that sync to this server (and others, of course) seem to ignore it: +GPS_NMEA(1) .GPS.0 l7 16 3770.0000.007 0.001 oPPS(0) .PPS.0 l5 16 3770.0000.007 0.001 ... ntp.nmi.nl .IRIG. 1 u 23 64 377 12.778 49.101 0.462 other system: *GENERIC(0) .DCFa. 0 l 55 64 3370.000 -2.421 2.390 +adsl.remco.org .GPS.1 u 504 1024 377 19.5813.159 0.188 ... ntp.nmi.nl .IRIG. 1 u 535 1024 377 12.146 52.565 0.044 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, cable and SDSL connected systems, synced to GPS+PPS, DCF77, MSF and systems on the internet) - reference time too old Folkert van Heusden -- To MultiTail einai ena polymorfiko ergaleio gia ta logfiles kai tin eksodo twn entolwn. Prosferei: filtrarisma, xrwmatismo, sygxwneysi, diaforetikes provoles. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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, cable and SDSL connected systems, synced to GPS+PPS, DCF77, MSF and systems on the internet) - reference time too old I mean: they are the Dutch national standard for time, they're part of the clocks that define UTC. Even if this service is a toy for them it is a shame it is broken! Folkert van Heusden -- -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 high. It is the high root distance (which includes the root dispersion) that is causing the server to be rejected. The systems I checked that sync to this server (and others, of course) seem to ignore it: *GENERIC(0) .DCFa. 0 l 55 64 3370.000 -2.421 2.390 +adsl.remco.org .GPS.1 u 504 1024 377 19.5813.159 0.188 ... ntp.nmi.nl .IRIG. 1 u 535 1024 377 12.146 52.565 0.044 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 It is not working with nptd, either. There is no character in front of it, which means that it is being rejected. If you do rv for the association, you will see a code indicating that the the distance is too high. now: - root dispersion too high and therefore root distance is too high, and therefore it is rejected as a source. - offset too high; 52ms (tried from ADSL, cable and SDSL connected The very large root distance would make 52ms highly acceptable, if the clock weren't being rejected. 52ms is well within the, nearly, 4,000ms uncertainty. In reality, this figure could either represent that it really has been unsynchronised for three days, but is drifting at rather less than 15ppm (and 15ppm is really rather pessimistic), or that you have a calibration error on your PPS input. systems, synced to GPS+PPS, DCF77, MSF and systems on the internet) - reference time too old DCF is not good for very high accuracy time. Someone mentioned that this machine is only intended for synchronising Windows. I don't believe that w32time performs a root distance check on its servers. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 Clock Update Time: Jan 5, 2009 08:45:47,4493 UTC Does a valid NTP source need to set the reftime to something valid? Does the ntp spec say so? Yes. Quote 'Time when the system clock was last set or corrected, in NTP timestamp format' unquote. So this can be years in the past? If so: why is ntpdate then refusing this server? Is it because of the huge root dispersion? Yes. You don't want to trust this time source. Use a pool server and move on. The folk providing this time source either don't understand how to operate a server or don't care enough to monitor its performance. Which is a bit weird for a standards organization. It is like if a car company was found not to know what an engine was or how they operate. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 time is too old, which means the root dispersion is too high. It is the high root distance (which includes the root dispersion) that is causing the server to be rejected. The systems I checked that sync to this server (and others, of course) seem to ignore it: *GENERIC(0) .DCFa. 0 l 55 64 3370.000 -2.421 2.390 +adsl.remco.org .GPS.1 u 504 1024 377 19.5813.159 0.188 ... ntp.nmi.nl .IRIG. 1 u 535 1024 377 12.146 52.565 0.044 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 It is not working with nptd, either. There is no character in front of it, which means that it is being rejected. If you do rv for the association, you will see a code indicating that the the distance is too high. now: - root dispersion too high and therefore root distance is too high, and therefore it is rejected as a source. - offset too high; 52ms (tried from ADSL, cable and SDSL connected The very large root distance would make 52ms highly acceptable, if the clock weren't being rejected. 52ms is well within the, nearly, 4,000ms uncertainty. In reality, this figure could either represent that it really has been unsynchronised for three days, but is drifting at rather less than 15ppm (and 15ppm is really rather pessimistic), or that you have a calibration error on your PPS input. 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 something other than ntp (eg a separate oven controlled clock source driven by the world TAI standard)and thus ntp does not see it, and thinks that the last time the local clock was synchronized was a week ago, while actually the local clock is continually synchronized to far far better than ntp could ever hope to do it. But noone told ntp. systems, synced to GPS+PPS, DCF77, MSF and systems on the internet) - reference time too old DCF is not good for very high accuracy time. Someone mentioned that this machine is only intended for synchronising Windows. I don't believe that w32time performs a root distance check on its servers. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 it. Using the regular ntp daemon works fine. Could someone enlighten me why it is refused? I mean: has gone too long without sync seems a little odd as it is supposed to be connected to real atomic clocks. folk...@belle:~/bin$ /usr/sbin/ntpdate -d -q -u -t 1 -p 4 ntp.nmi.nl 7 Jan 17:49:01 ntpdate[22293]: ntpdate 4.2@1.1520-o Wed Jul 16 12:36:25 UTC 2008 (1) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) 134.221.205.12: Server dropped: Server has gone too long without sync server 134.221.205.12, port 123 stratum 1, precision -18, leap 00, trust 000 refid [IRIG], delay 0.03783, dispersion 0.00012 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 0.0 0.0 0.0 0.0 filter offset: 0.023514 0.023034 0.023029 0.023167 0.00 0.00 0.00 0.00 delay 0.03783, dispersion 0.00012 offset 0.023167 7 Jan 17:49:01 ntpdate[22293]: no server suitable for synchronization found ( 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 Originate Time Stamp: Jan 8, 2009 10:15:39,0507 UTC Receive Time Stamp: Jan 8, 2009 10:15:39,0375 UTC Transmit Time Stamp: Jan 8, 2009 10:15:39,0376 UTC The Root dispersion does not look too healthy, too... Root Dispersion:3,9689 sec This really looks like they should have a look at their NTP server and its IRIG source. Why this server is accepted by ntpd is a miracle for me. Only chance I would see is if you have no other sources configured. Regards, Heiko ntpd will mobilize an association with that server, but its root dispersion is too large to be selected as a time source. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 ntp daemon works fine. Could someone enlighten me why it is refused? I mean: has gone too long without sync seems a little odd as it is supposed to be connected to real atomic clocks. folk...@belle:~/bin$ /usr/sbin/ntpdate -d -q -u -t 1 -p 4 ntp.nmi.nl 7 Jan 17:49:01 ntpdate[22293]: ntpdate 4.2@1.1520-o Wed Jul 16 12:36:25 UTC 2008 (1) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) 134.221.205.12: Server dropped: Server has gone too long without sync server 134.221.205.12, port 123 stratum 1, precision -18, leap 00, trust 000 refid [IRIG], delay 0.03783, dispersion 0.00012 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 0.0 0.0 0.0 0.0 filter offset: 0.023514 0.023034 0.023029 0.023167 0.00 0.00 0.00 0.00 delay 0.03783, dispersion 0.00012 offset 0.023167 7 Jan 17:49:01 ntpdate[22293]: no server suitable for synchronization found ( 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 Originate Time Stamp: Jan 8, 2009 10:15:39,0507 UTC Receive Time Stamp: Jan 8, 2009 10:15:39,0375 UTC Transmit Time Stamp: Jan 8, 2009 10:15:39,0376 UTC Is there a KISS code associated with this? This looks like what Dave implemented for telling clients to go away. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] ntpdate refusing ntp.nmi.nl
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 refused? I mean: has gone too long without sync seems a little odd as it is supposed to be connected to real atomic clocks. folk...@belle:~/bin$ /usr/sbin/ntpdate -d -q -u -t 1 -p 4 ntp.nmi.nl 7 Jan 17:49:01 ntpdate[22293]: ntpdate 4.2@1.1520-o Wed Jul 16 12:36:25 UTC 2008 (1) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) 134.221.205.12: Server dropped: Server has gone too long without sync server 134.221.205.12, port 123 stratum 1, precision -18, leap 00, trust 000 refid [IRIG], delay 0.03783, dispersion 0.00012 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 0.0 0.0 0.0 0.0 filter offset: 0.023514 0.023034 0.023029 0.023167 0.00 0.00 0.00 0.00 delay 0.03783, dispersion 0.00012 offset 0.023167 7 Jan 17:49:01 ntpdate[22293]: no server suitable for synchronization found ( http://nmi.nl/index.php?pageId=1215lg=nl ) Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff- view', vs. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 (just to see if it was Folkert reachable) but ntpdate refuses it. Using the regular ntp daemon Folkert works fine. Could someone enlighten me why it is refused? I mean: Folkert has gone too long without sync seems a little odd as it is Folkert supposed to be connected to real atomic clocks. Have you tried the new sntp code instead of ntpdate? -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 see if it was reachable) but ntpdate refuses it. Using the regular ntp daemon works fine. Could someone enlighten me why it is refused? I mean: has gone too long without sync seems a little odd as it is supposed to be connected to real atomic clocks. folk...@belle:~/bin$ /usr/sbin/ntpdate -d -q -u -t 1 -p 4 ntp.nmi.nl 7 Jan 17:49:01 ntpdate[22293]: ntpdate 4.2@1.1520-o Wed Jul 16 12:36:25 UTC 2008 (1) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) 134.221.205.12: Server dropped: Server has gone too long without sync server 134.221.205.12, port 123 stratum 1, precision -18, leap 00, trust 000 refid [IRIG], delay 0.03783, dispersion 0.00012 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 0.0 0.0 0.0 0.0 filter offset: 0.023514 0.023034 0.023029 0.023167 0.00 0.00 0.00 0.00 delay 0.03783, dispersion 0.00012 offset 0.023167 7 Jan 17:49:01 ntpdate[22293]: no server suitable for synchronization found ( http://nmi.nl/index.php?pageId=1215lg=nl ) Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff- view', vs. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate refusing ntp.nmi.nl
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 daemon works fine. Could someone enlighten me why it is refused? I mean: has gone too long without sync seems a little odd as it is supposed to be connected to real atomic clocks. folk...@belle:~/bin$ /usr/sbin/ntpdate -d -q -u -t 1 -p 4 ntp.nmi.nl 7 Jan 17:49:01 ntpdate[22293]: ntpdate 4.2@1.1520-o Wed Jul 16 12:36:25 UTC 2008 (1) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) receive(134.221.205.12) transmit(134.221.205.12) 134.221.205.12: Server dropped: Server has gone too long without sync server 134.221.205.12, port 123 stratum 1, precision -18, leap 00, trust 000 refid [IRIG], delay 0.03783, dispersion 0.00012 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 0.0 0.0 0.0 0.0 filter offset: 0.023514 0.023034 0.023029 0.023167 0.00 0.00 0.00 0.00 delay 0.03783, dispersion 0.00012 offset 0.023167 7 Jan 17:49:01 ntpdate[22293]: no server suitable for synchronization found The reference time is too far out, over 2 days. Looks like it's been coasting. Be nice if it responded to ntpq. ( http://nmi.nl/index.php?pageId=1215lg=nl ) Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff- view', vs. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
