Re: [ntp:questions] ntpd stays synced after loosing gps
Thanks, Dave. That's exactly what I didn't understand. Will the server without sync lower it's stratum somewhen? According to tos maxdist maybe? Let me explain. I need to set some criteria of local clock goodness. Goodness for me means low root dispersion and exact time. And I need to set this criteria simultaneously on proxy and on clients. For now I used sync_unspec in ntpd status, but proxy sets sync_unspec immediately after loosing GPS and clients set it according to big root dispersion of proxy after some hours maybe. What system variable can I use? I think that good OS clock = (stratum 16) ( rootdisp MAX_DISP ) ( offset MAX_OFFSET ) In this case server with no sync will be bad in any case, server which was synced will become bad after some time, server which has big offset will be marked bad too. Stratum needs to be checked cause just started server have offset and rootdisp = 0 Am I right? 2011/5/11 Dave Hart daveh...@gmail.com On Wed, May 11, 2011 at 15:29 UTC, Nickolay Orekhov nowh...@mail.ru wrote: Other devices should also have status unsync and stop syncing but they will continue to sync from unsynced source with stratum 1 infinitely. No, they will reject the source once its root dispersion (rootdisp= in ntpq rv) exceeds the client's tos maxdist threshold (in seconds, default 1.5 in ntp-dev). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On Thu, May 12, 2011 at 07:13 UTC, Nickolay Orekhov nowh...@mail.ru wrote: Will the server without sync lower it's stratum somewhen? According to tos maxdist maybe? No, the only change in system variables will be the increased rootdisp. [...] What system variable can I use? I think that good OS clock = (stratum 16) ( rootdisp MAX_DISP ) ( offset MAX_OFFSET ) [...] Stratum needs to be checked cause just started server have offset and rootdisp = 0 Am I right? I can't judge what is good for you, but I will note you can check for leap != 11 (in binary, the default base for the leap variable output in ntpq) to avoid believing the 0 offset and dispersion at startup. Note leap 00, 01, and 10 are all indicating a synchronized ntpd, while leap == 11 indicates unsynchronized. You may find the stratum test redundant if you test leap. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On Wed, May 11, 2011 at 05:17:14AM +, Dave Hart wrote: 2011/5/11 Николай Орехов nowh...@mail.ru: Thanks, I'll try it! But is the recent tarball stable enough? I'm using latest 4.2.6 with some minor changes to support my LassenIQ TSIP and I need it to be very stable. I prefer ntp-dev in general over ntp-stable, but my perspective may be warped. Could you provide me link to this bug and fixes so I can make a patch? No, I'm afraid I can't. I recall the problem you describe, and I haven't seen it in ntp-dev for a while, so I'm pretty sure it was fixed after 4.2.6 based on your experience, but I'd like to confirm that, as we are likely to start the push to polish 4.2.7 into a (-stable) 4.2.8 soon. I do not know of an existing bug report for the behavior, though I haven't searched for one either. Similarly while I believe it to be fixed in more recent versions, I can't at this point suggest when it was fixed or which change fixed it. I think it's the bug #1554, which was fixed only in 4.2.7. https://bugs.ntp.org/show_bug.cgi?id=1554 -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
Thanks, Dave, Miroslav. 4.2.7p164 bug has gone, problem solved! 2011/5/11 Miroslav Lichvar mlich...@redhat.com On Wed, May 11, 2011 at 05:17:14AM +, Dave Hart wrote: 2011/5/11 Николай Орехов nowh...@mail.ru: Thanks, I'll try it! But is the recent tarball stable enough? I'm using latest 4.2.6 with some minor changes to support my LassenIQ TSIP and I need it to be very stable. I prefer ntp-dev in general over ntp-stable, but my perspective may be warped. Could you provide me link to this bug and fixes so I can make a patch? No, I'm afraid I can't. I recall the problem you describe, and I haven't seen it in ntp-dev for a while, so I'm pretty sure it was fixed after 4.2.6 based on your experience, but I'd like to confirm that, as we are likely to start the push to polish 4.2.7 into a (-stable) 4.2.8 soon. I do not know of an existing bug report for the behavior, though I haven't searched for one either. Similarly while I believe it to be fixed in more recent versions, I can't at this point suggest when it was fixed or which change fixed it. I think it's the bug #1554, which was fixed only in 4.2.7. https://bugs.ntp.org/show_bug.cgi?id=1554 -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On Wed, May 11, 2011 at 07:31 UTC, Miroslav Lichvar mlich...@redhat.com wrote: On Wed, May 11, 2011 at 05:17:14AM +, Dave Hart wrote: 2011/5/11 Николай Орехов nowh...@mail.ru: Could you provide me link to this bug and fixes so I can make a patch? No, I'm afraid I can't. I think it's the bug #1554, which was fixed only in 4.2.7. https://bugs.ntp.org/show_bug.cgi?id=1554 You're right, Miroslav, thanks. It wasn't so long ago, I must repress negative memories :) http://lists.ntp.org/pipermail/bk-ntp-dev-send/2010-September/001945.html That message has the ntp_proto.c patches that went into 4.2.7p58, which resolved this bug. I suspect only the first hunk (adding a call to clock_select()) is needed. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
Just one more question :-) After loosing sync, server should lower it's stratum so other servers can't synchronize with it, but: ntpq pe remote refid st t when poll reach delay offset jitter == PPS(0) .PPSE. 0 l 153800.0005.051 0.000 GENERIC(0) .TSIP. 0 l 158800.000 -6.027 0.000 ntpq rv associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, version=ntpd 4.2.7p164@1.2483 Wed May 11 07:27:34 UTC 2011 (1), processor=UNKNOWN, system=QNX/6.5.0, leap=00, stratum=1, precision=-10, rootdelay=0.000, rootdisp=9.456, refid=PPSE, reftime=d174f4ad.2bb91753 Wed, May 11 2011 17:42:37.170, clock=d174f549.8e4f7235 Wed, May 11 2011 17:45:13.555, peer=0, tc=3, mintc=3, offset=5.051, frequency=219.166, sys_jitter=0.977, clk_jitter=0.977, clk_wander=0.160, tai=33, leapsec=20060101, expire=20080628 ntpq ass ind assid status conf reach auth condition last_event cnt === 1 17646 8023 yesno nonereject unreachable 2 2 17647 8023 yesno nonereject unreachable 2 ntpq I see that stratum Is still = 1 and servers could take this server time. Why? 2011/5/11 Dave Hart daveh...@gmail.com On Wed, May 11, 2011 at 07:31 UTC, Miroslav Lichvar mlich...@redhat.com wrote: On Wed, May 11, 2011 at 05:17:14AM +, Dave Hart wrote: 2011/5/11 Николай Орехов nowh...@mail.ru: Could you provide me link to this bug and fixes so I can make a patch? No, I'm afraid I can't. I think it's the bug #1554, which was fixed only in 4.2.7. https://bugs.ntp.org/show_bug.cgi?id=1554 You're right, Miroslav, thanks. It wasn't so long ago, I must repress negative memories :) http://lists.ntp.org/pipermail/bk-ntp-dev-send/2010-September/001945.html That message has the ntp_proto.c patches that went into 4.2.7p58, which resolved this bug. I suspect only the first hunk (adding a call to clock_select()) is needed. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On Wed, May 11, 2011 at 05:48:21PM +0600, Nickolay Orekhov wrote: Just one more question :-) After loosing sync, server should lower it's stratum so other servers can't synchronize with it, but: ntpq pe remote refid st t when poll reach delay offset jitter == PPS(0) .PPSE. 0 l 153800.0005.051 0.000 GENERIC(0) .TSIP. 0 l 158800.000 -6.027 0.000 ntpq rv associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, version=ntpd 4.2.7p164@1.2483 Wed May 11 07:27:34 UTC 2011 (1), processor=UNKNOWN, system=QNX/6.5.0, leap=00, stratum=1, precision=-10, rootdelay=0.000, rootdisp=9.456, refid=PPSE, That has changed with ntp version 4, it doesn't increase stratum and change leap to unsync, it will keep increasing the root dispersion instead. When the distance reacheas a certain limit, the clients will switch to another source. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On 2011-05-11, ??? ?? nowh...@mail.ru wrote: Thanks, I'll try [ntp-dev]! But is the recent tarball stable enough? Yes. I have a flock of ~ 10 Debian systems which track the current ntp-dev. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
And what if it has no other source ? May be you could give me an advice on my system. I have one device synced from GPS and other devices synced from it by NTP. Often there will be only one NTP server. When sync server looses GPS I set some variable to unsync ( according to ntpd system status ). Other devices should also have status unsync and stop syncing but they will continue to sync from unsynced source with stratum 1 infinitely. 2011/5/11 Miroslav Lichvar mlich...@redhat.com ntpq rv associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, version=ntpd 4.2.7p164@1.2483 Wed May 11 07:27:34 UTC 2011 (1), processor=UNKNOWN, system=QNX/6.5.0, leap=00, stratum=1, precision=-10, rootdelay=0.000, rootdisp=9.456, refid=PPSE, That has changed with ntp version 4, it doesn't increase stratum and change leap to unsync, it will keep increasing the root dispersion instead. When the distance reacheas a certain limit, the clients will switch to another source. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On May 11, 2011, at 8:29 AM, Nickolay Orekhov wrote: And what if it has no other source ? If your priority is to keep all your machines sync'ed with each other, you're still fine. On the other hand, if your priority is to keep machines synch'ed to real time, well, you ought to provide greater redundancy than a single point of failure. May be you could give me an advice on my system. I have one device synced from GPS and other devices synced from it by NTP. Often there will be only one NTP server. Why only one? Either pick three or so local machines and set them up as peers of the main time source using the GPS, or give them all GPS receivers, or setup references to public stratum-1 or -2 servers, or use the NTP pool. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On Wed, May 11, 2011 at 15:29 UTC, Nickolay Orekhov nowh...@mail.ru wrote: Other devices should also have status unsync and stop syncing but they will continue to sync from unsynced source with stratum 1 infinitely. No, they will reject the source once its root dispersion (rootdisp= in ntpq rv) exceeds the client's tos maxdist threshold (in seconds, default 1.5 in ntp-dev). That's slightly oversimplified, because the source's root dispersion is added to the distance from the client's hop to the source before the comparison: /* * A distance error for a remote peer occurs if the root * distance is greater than or equal to the distance threshold * plus the increment due to one host poll interval. */ if (!(peer-flags FLAG_REFCLOCK) root_distance(peer) = sys_maxdist + clock_phi * ULOGTOD(peer-hpoll)) rval |= TEST11; /* distance exceeded */ You seem to be assuming that the intermediate ntpd should act like a proxy for its source to its clients. That's not how ntpd operates -- it disciplines the OS clock into sync with its source(s), and serves clients using that OS clock, simultaneously providing the maximum error estimate (in seconds) referred to as the root distance or root dispersion. When the intermediate ntpd has lost its sources, it is still in sync with UTC initially, and only slowly drifts away over time. As a result, it is still a useful source, though its usefulness decays as its root distance increases by 15 usec/sec (15 PPM) to account for the length of time it's been freewheeling since the loss of all its sources. You can accelerate the process of clients rejecting the intermediate ntpd as a source by using tinker dispersion (units are PPM or usec/sec, default 15) on the intermediate ntpd to cause its root dispersion to grow faster. The documentation for tinker notes: The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On Wed, May 11, 2011 at 8:29 AM, Nickolay Orekhov nowh...@mail.ru wrote: And what if it has no other source ? May be you could give me an advice on my system. I have one device synced from GPS and other devices synced from it by NTP. Often there will be only one NTP server. When sync server looses GPS I set some variable to unsync ( according to ntpd system status ). Other devices should also have status unsync and stop syncing but they will continue to sync from unsynced source with stratum 1 infinitely. If you have a requirement for a robust system then you need redundancy. Just to handle failures and normal system maintanance you need two of everything (at least) and if you want to be able to detect subtle errors where the GPS is not working perfetly you need at least three. A cheaper way to go is to use a set of (say) five pool NTP servers. Set up two NTP servers and connect each of these to the five pool servers and then point allof your clients at both of your local NTP servers. If you need more accuracy then add a GPS receiver to each of the two servers. If you want to be able to detect problems with GPS you need three DIFFERENT GPS receivers made by three DIFFERENT companies. But you can also use the set of five pool servers as a check on the GPS. There are just a few simple rules. The first comes from an old joke that just happnes to be true 1) A man with one watch kows what time it is, A mand with two watches is never sure. So clearly you need more than two if you want ot be sure. Three UNRELATED clocks are the minimum. If you care about being sure of the time. Pool servers, GPSes in any combination 2) There should be no single point of failure. Any service that fails, any GPS antenna that fails and so on should not bring the whole system to a halt. This means two of everything that is important. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ntpd stays synced after loosing gps
Hello! Here's my config: # TSIP reference clock server 127.127.8.0 mode 138 prefer maxpoll 3 fudge 127.127.8.0 refid TSIP time1 0.08 When GPS is connected system status shows sync_uhf_radio When I disconnect GPS antenna it still shows the same, however GPS marked as unreachable: ntpq pe remote refid st t when poll reach delay offset jitter == *GENERIC(0) .TSIP. 0 l 359800.0001.944 0.000 ntpq ass ind assid status conf reach auth condition last_event cnt === 1 36188 8653 yesno none sys.peer unreachable 5 ntpq rv associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, version=ntpd 4.2.6p3@1.2290 Tue May 10 06:09:44 UTC 2011 (2), processor=UNKNOWN, system=QNX/6.5.0, leap=00, stratum=1, precision=-10, rootdelay=0.000, rootdisp=20.739, refid=TSIP, reftime=d1737f28.b8b857bd Tue, May 10 2011 15:08:56.721, clock=d1738091.ff8dc0aa Tue, May 10 2011 15:14:57.998, peer=36188, tc=3, mintc=3, offset=1.944, frequency=257.971, sys_jitter=12.296, clk_jitter=1.084, clk_wander=0.048, tai=33, leapsec=20060101, expire=20080628 ntpq rv 36188 associd=36188 status=8653 conf, sel_sys.peer, 5 events, unreachable, srcadr=GENERIC(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=11, stratum=0, precision=-10, rootdelay=0.000, rootdisp=0.000, refid=TSIP, reftime=d1737f28. Tue, May 10 2011 15:08:56.000, rec=d1737f28.b8b857bd Tue, May 10 2011 15:08:56.721, reach=000, unreach=0, hmode=3, pmode=4, hpoll=3, ppoll=3, headway=0, flash=00 ok, keyid=0, ttl=0, offset=1.944, delay=0.000, dispersion=15937.500, jitter=0.000, filtdelay= 0.000.000.000.000.000.000.000.00, filtoffset=0.000.000.000.000.000.000.000.00, filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 ntpq cv 36188 associd=36188 status=0043 , 4 events, clk_fault, device=Trimble GPS (TSIP) receiver, timecode=\x10X\x02\x05\x00'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00M-(\x00\x00\x00\x00\x00\x00M-(0\x00\x00\x00\x0fH\xff\x00\x00\x06c\x01\xff\x00\x04\x00\x0f\x10\x03, poll=56, noreply=0, badformat=0, baddata=1, fudgetime1=80.000, stratum=0, refid=TSIP, flags=1, refclock_time=d1738098.47e6 Tue, May 10 2011 9:15:04.281, refclock_status=NOT SYNCHRONIZED; TIME CODE NOT CONFIRMED; TIME CODE; (LEAP INDICATION; POSITION), refclock_format=Trimble TSIP, refclock_states=NOMINAL: 00:00:56 (12.50%); *FAULT: 00:06:27 (86.38%); ILLEGAL DATE: 00:00:05 (1.11%); running time: 00:07:28, trimble_version=1.16 (1906/2/2), trimble_iooptions=00 00 23 00, trimble_satview=mode: 0x0-AUTO, PDOP 0.00, HDOP 0.00, VDOP 0.00, TDOP 0.00, 0 satellites in view: , trimble_receiver_health=no usable satellites, Battery backup failed, Antenna feed line fault, trimble_status=machine id 0x5a, Battery Powered Time Clock Fault, Superpackets supported I think that condition of unreachable GPS shouldn't be sys.peer? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On 2011-05-10, ??? ?? nowh...@mail.ru wrote: # TSIP reference clock server 127.127.8.0 mode 138 prefer maxpoll 3 fudge 127.127.8.0 refid TSIP time1 0.08 When GPS is connected system status shows sync_uhf_radio When I disconnect GPS antenna it still shows the same, however GPS marked as unreachable: Have you tried omitting prefer ? -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
On Tue, May 10, 2011 at 09:16 UTC, Николай Орехов nowh...@mail.ru wrote: When GPS is connected system status shows sync_uhf_radio When I disconnect GPS antenna it still shows the same, however GPS marked as unreachable: I recall a bug which I believe has since been fixed which caused deferred no_sys_peer events (they wouldn't occur until the same second as the immediately-following selection of a new sys.peer). I would appreciate it if you could repeat your test with a recent 4.2.7 tarball to verify it has been fixed. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
Thanks, I'll try it! But is the recent tarball stable enough? I'm using latest 4.2.6 with some minor changes to support my LassenIQ TSIP and I need it to be very stable. Could you provide me link to this bug and fixes so I can make a patch? 2011/5/11 Dave Hart h...@ntp.org On Tue, May 10, 2011 at 09:16 UTC, Николай Орехов nowh...@mail.ru wrote: When GPS is connected system status shows sync_uhf_radio When I disconnect GPS antenna it still shows the same, however GPS marked as unreachable: I recall a bug which I believe has since been fixed which caused deferred no_sys_peer events (they wouldn't occur until the same second as the immediately-following selection of a new sys.peer). I would appreciate it if you could repeat your test with a recent 4.2.7 tarball to verify it has been fixed. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd stays synced after loosing gps
2011/5/11 Николай Орехов nowh...@mail.ru: Thanks, I'll try it! But is the recent tarball stable enough? I'm using latest 4.2.6 with some minor changes to support my LassenIQ TSIP and I need it to be very stable. I prefer ntp-dev in general over ntp-stable, but my perspective may be warped. Could you provide me link to this bug and fixes so I can make a patch? No, I'm afraid I can't. I recall the problem you describe, and I haven't seen it in ntp-dev for a while, so I'm pretty sure it was fixed after 4.2.6 based on your experience, but I'd like to confirm that, as we are likely to start the push to polish 4.2.7 into a (-stable) 4.2.8 soon. I do not know of an existing bug report for the behavior, though I haven't searched for one either. Similarly while I believe it to be fixed in more recent versions, I can't at this point suggest when it was fixed or which change fixed it. Thanks, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
