[ntp:questions] Re: Ref Clk ID and Leap still valid after sys_peer is lost?

user at domain.invalid user at domain.invalid
Thu May 4 17:09:23 UTC 2006


Martin,

This is the expressly intended behavior. There is no such thing as 
"stale" time, only the perception on the part of a client of the 
expected maximum error and nominal error of the server.

If a server loses all synchronization sources, the intended (and actual) 
result is that the synchronization distance continues to increase with 
time, eventually exceeding a sanity threshold set by the client. The 
server doesn't know what this threshold is, especially at very long poll 
intervals up to 36 hours. So, the server freezes at its last stratum, 
delay, offset, etc., and reveals the maximum error equal to the 
synchronization distance calculated as one-half the roundtrip delay plus 
dispersion plus residuals.

Dave

Martin Burnicki wrote:

> mlawdawg at comcast.net wrote:
> 
>>After my NTP server loses it's sys_peer, it still replies to client
>>requests using the "stale" sys_stratum, sys_refid, and sys_leap values.
>>I don't think this is the correct behavior. I think the sys_stratum,
>>sys_refid, and sys_leap should also be reset when sys_peer is reset to
>>NULL in peer_clear(). The 4.2.0 code DOES clear the peer->leap,
>>peer->stratum, and peer->refId, but not their sys_xxx var counterparts.
>>The sys_refid and sys_leap vars are used when responding to client pkts
>>and shouldn't contain "stale" values.
>>
>>When sys_peer is reset to NULL, shouldn't sys_stratum, sys_refid, and
>>sys_leap be reset also?
>>
>>I'm essentially arguing for the following source code change to
>>ntp_proto.c's function peer_clear():
>>
>>if (peer == sys_peer)
>>{
>>    sys_peer = NULL;
>>    /* START: also clear these sys_xxx vars */
>>    sys_leap = LEAP_NOTINSYNC;
>>    sys_stratum = STRATUM_UNSPEC;
>>    memcpy(&sys_refid, ident, 4);
>>    sys_peer_refid = 0;
>>    /* END: also clear these sys_xxx vars */
>>}
>>
>>Cmts?
> 
> 
> I had once opened a bugzilla issue for this:
> https://ntp.isc.org/bugs/show_bug.cgi?id=487
> 
> However, I had to learn that this "works as designed". So I'm afrait your
> patch won't be accepted.
> 
> Martin




More information about the questions mailing list