[ntp:hackers] Further to the timestamping issue

David L. Mills mills at udel.edu
Mon Jun 16 14:33:58 UTC 2008


Poul-Henning Kamp wrote:

> In message <4855E47F.2030203 at udel.edu>, "David L. Mills" writes:
>
>>> * Change/Define Root Dispersion to be useful/meaningful
>>> While statistically correct, the number is of no use and often
>>> deeply misleading.
>>
>> I submit the current semantics are correct, although maybe not
>> as clear in the documentation. If you found this confusing, you should
>> have spoken up before.
>
>
> I did not say they were not correct, I said they were of no use.
>
> And as a result of that, they are more likely than not to be
> correct on the wild network since people don't bother setting
> them right for their stratum 1 servers.
>
> Some of this originates with the software, for instance most DCF77
> refclocks do not use the same definition of root delay as your
> quoted for WWVB.

I mentioned WWV, not WWVB.With WWV I can accurately characterize the 
propagation path up to the antenna. Most drivers don't have knowledge of 
the transmission path, but very little is gained by doing that anyway. 
The intent of the delay/dispersion/jitter semantics is to provide a 
maximum error statistic and expected error statistic. Device driver 
authors should read the specification and understand the error budget. 
If other drivers don't follow the intended semantics, that's not the 
fault of the semantics.

>>> * Fix leapsecond handling.
>>> Add timestamp of next scheduled leapsecond, so that clients can
>>> handle the event correctly, even if they are offline at the time.
>>
>> You need to be more explicit about "fix leapsecond handlin"g.
>
>
> The current leapsecond handling gives a very short warning about
> an impending leapsecond, despite the fact that we know six months
> in advance that it will happen.
>
> A device which is "off the net" during the short interval around
> the leapsecond, will not know to do the right thing.
>
> This is a particular problem with DCF77 stratum1 servers which
> only get 1 hour leap-second warning in PTB's transmissions.
>
> We should add a field that can contain the time of the next
> scheduled leapsecond:
>
> "Next leapsecond is at [32bit seconds]"
>
> So we can set it at the time when we receive The Bulletin from Mr.
> Gambis.

Pleas, please, read the documentation. Leapsecond handling is not as you 
assume. Warnings can be months in advance if armed from the leapseconds 
file. The leapseconds values include the epoch of the next/last leap, 
the epoch of expiry and the TAI at the next leap and up to a month if 
from leap bits. We don't need a field for the next leap; we already have 
that. And, once the epoch has been determined, the client can go off-net 
and still leap the leap.



More information about the hackers mailing list