[ntp:questions] Re: NTP and DCF77 leap logs

Serge Bets serge.bets at NOSPAM.laposte.invalid
Fri Jan 6 23:54:27 UTC 2006


 On Friday, January 6, 2006 at 19:12:25 +0000, David L. Mills wrote:

> Serge Bets wrote:
>> The coast and step behaviour can't be placed in the acceptable
>> category.
>>  - Gives wrong time on the machine.
>>  - Serves wrong time to downstream clients.
>>  - Does a step backward at some unpredictable moment.
>>  - Depends on sources leaping well or not.

And that step is a time reset, wiping the carefully accumulated history.


> (a) upstream sources indicate a leap and the kernel does not implement
> a leap function

This case is perhaps not the perfect one, but is the best available on
some platforms. It is there considered to be normal conditions. To coast
and step is ugly. A nicer behaviour would be: Ntpd performs the leap,
compensating kernel deficiency.


The other cases (b), (c), and (d) are broken: No way to be sure if it's
really a leap. Coast and step is acceptable. The response could be
changed if we knew in advance a leap is occuring, either thru other
sources or thru leapseconds file. Then kernel or ntpd would leap in
time, and perhaps we receive some wrong samples until the bad source
itself leaps late.


> Once you consider these cases in detail and provide a compromise
> solution, I would be very happy to learn your opinion.

So I'll reformulate: Coast and step is ugly. Doing such things in fubar
conditions is indeed acceptable, when no better behaviour can be
imagined. But doing it in normal conditions is not.

The scope of my coast and step criticism was case (a) only.

How many different platforms have non-leaping kernels? How many
stratum 1 or 2 servers run ntpd on such platforms? How many good leaping
kernel clients can be disturbed by such servers? What percentage of the
December 2005 leap problems can be attributed directly or indirectly to
coast and step?


Serge.
-- 
Serge point Bets arobase laposte point net




More information about the questions mailing list