[ntp:hackers] Does ntpd need to whine more ?

David L. Mills mills at udel.edu
Mon Oct 3 14:24:42 UTC 2005


Martin,

I say again, an intermediate server cannot directly determine for a 
downstream client whether an upstream server has or has not "lost" 
synchronization; it can only reveal in the root distance how much the 
maximum error has accumulated. Only the dependent client can judge from 
this statistic whether or not to believe the time.

The present behavior is not a bug; it is at the definitive core of the 
design. It is necessary in order to support very long poll intervals as 
with the modem driver.

Dave

Martin Burnicki wrote:

> Poul-Henning Kamp wrote:
> [...]
>
>> It's not LOCALCLOCK I'm after, it's the fact that ntpd doesn't tell
>> the user that it has lost external sync.
>
>
> Yes, that's exactly why I've recently opened a bug on this:
> https://ntp.isc.org/bugs/show_bug.cgi?id=487
>
> However, I've had to learn that everything is working as designed, and 
> that
> it's absolutely OK that if once ntpd has synchronized to an upstream 
> ref time
> source, it keeps it good stratum forever even if none of the upstream 
> sources
> is available anymore.
>
> What I've not learned is what I should tell normal users who just want to
> check whether their time sync network is in sync.
>
>> I'm also wondering the wisdom of not slamming the poll rate back
>> to 64 seconds when the shift register runs empty. With a poll
>> rate that has grown to 1024 it takes an hours after connectivity
>> is back before it even pays attention to the timestamps and
>> several hours before it is back in tolerance.
>
>
> Agreed.
>
>
> Best regards,
>
> Martin




More information about the hackers mailing list