[ntp:questions] Re: How to handle leap second condition correctly?
David L. Mills
mills at udel.edu
Sat Jun 11 17:45:45 UTC 2005
SNTP implementations are not required to discipline the clock frequency
and can in principle step the clock, have huge sawtooth errors and
believe falsetickers. If the implementation operates with a reference
clock, it is expected to be well behaved. If it operates with one or
more upstream servers, it could misbehave and create downstream chaos.
For instance, a SNTP server with 100 PPM frequency error and updating
once per day would have a sawtooth error of over eight seconds. A
downstream NTP client would not work at all. A downstream SNTP client
might not care very much, but then I wouldn't consider those clocks
David Woolley wrote:
> In article <ywn9psutvr5k.fsf at ntp1.isc.org>,
> Harlan Stenn <stenn at ntp1.isc.org> wrote:
>>An SNTP server should not ordinarily be telling ANYBODY what time it is.
> An SNTP server that isn't telling someone the time is a total waste of
> resources. Telling clients the time is the only reason for an SNTP
> server to exist!
> Are you possibly trying to say that an SNTP client should not also act
> as a server? Whilst true, this is only a SHOULD NOT, not a MUST NOT,
> and Windows violates this rule anyway, which means it has become
> unenforceable (ignoring that Windows has more serious protocol violations).
> (SHOULD NOTs are things that shouldn't normally be done but are permitted
> in exceptional circumstances.)
> In any case, the original article seems to have meant the server response
> to an SNTP client request, not really that the server had to be an SNTP
> server. Even if it were an SNTP server, there is nothing to indicate
> that it isn't directly connected to a proper reference clock.
> I would say that the answer was that an SNTP client isn't normally expected
> to maintain the clock that well that it can't just ignore the leap warning
> (it shouldn't ignore the alarm state) and just respond to the step in time
> when it occurs. However, if it did want to honour it, it would refrain
> from asking the time in the immediate vicinity of the two times a year
> that leap seconds may be implemented, and should adjust its internal idea
> of UTC time (which may or may not be able to represent second 59 minutes
> and 60 seconds) at the nominal time at which leap seconds are allowed, and
> in the direction indicated. If it cannot represent 60 seconds, it may have
> to compromise this to maintain monotonicity, if that is important.
> The reason I suggest not asking the time, is that and SNTP implementation is
> unlikely to have good filtering of outlyers, so may undo its automatic
> adjustment when it gets a response that indicates that the time hasn't quite
> passed, and then re-apply on the next sample.
More information about the questions