David, David J Taylor wrote: > Many thanks for your analysis. If NTP is capable of forgetting the false > announcement, that's great. However, I would like to know how to confirm > this on the particular system. Can anyone explain the significance of the > "leap_none" in the output below? > > C:\>ntpq -c rv > assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg, > version="ntpd [EMAIL PROTECTED] Dec 22 12:23:10 (UTC+01:00) 2005 (1)", > processor="unknown", system="WINDOWS/NT", leap=00, stratum=2, > precision=-23, rootdelay=1.395, rootdispersion=50.905, peer=53081, > refid=192.168.0.3, > reftime=c9991306.8c1ee90a Wed, Mar 7 2007 10:31:34.547, poll=10, > clock=c99919a7.de0c922d Wed, Mar 7 2007 10:59:51.867, state=4, > offset=7.139, frequency=11.194, jitter=0.583, noise=1.504, > stability=0.046, tai=0 > > Does "leap_none" tell me anything about the way this client will behave? > I've tried searching but haven't found a simple, plain English > explanation!
I'm not quite sure about this. Again, after just a quick look at this, there's a variable "leap_next" which is updated from the responses from the surviving upstream servers. If the corresponding flag is set in "leap_next" then the leap second announcement is also passed to the kernel to handle it (if kernel support is available) or it is evaluated by the specific leap second handler code in the Windows port. Occasionally, "leap_next" is copied to another variable "sys_leap" which is reported to ntpq queries. I've not yet had time to look at this closer. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
