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:
[EMAIL PROTECTED] 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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
