[ntpwg] [ntp:hackers] Further to the timestamping issue

[David L. Mills]

P-H,

I said nothing about new headers, only a reuse of the existing ones in 
interleaved modes, as detailed in the documents cited. However, you 
raise some other issues, with comments below. Inline comments are hard 
for me because for eyesight reasons I have to reformat in fixed-width 
and MIME fights me every step of the way.

Dave

Poul-Henning Kamp wrote:

> In message <485438C6.2080401 at udel.edu>, "David L. Mills" writes:
>
>> Not to bring up a dead horse, but I don't think everybody was completely
>> happy about the timestamp capture issue; [...]
>
>
> If we are going to roll a packet format revision, would it be prudent
> to consider all identified issues with the NTPv4 format:
>
> * Add a y2036 disabiguation field
> This is cheaper than increasing the width of all timestamps.
> One bit will go a long way, two would be enough for all of us.

We have had this discussion before. If you consider NTP a mechanism to 
set the clock in any era, even across eras, and agree to set it within 
68 years in the current era, no changes are necessary. In other words, 
if in 2038 you set the system time between 1970 and 2006 (give or take 
Unix), the clock will be correctly set. I did this experiment with 
current NTP and Solaris and it worked fine.

But, if you expect NTP to set the clock in Octobrer, 1582 starting from 
the 21st century, you would need the NTP era number. That could be 
carried in an extension field.

>
> * Add (optional) DUT1 transmission field

Again, an extension field. Like leapsecond wargings, you will need to 
define a mitigation procedure if more than one value was reported from 
local and/or remote sources.  You also need to specify how to get this 
intormation to potential applications. For this, I suggest the kernel 
interface ntp_gettime() as modified.

>
> * Change/Define contents of Root Delay to be useful/meaningful
> Practically all stratum 1 servers are uncalibrated/undefined.
>
> * Change/Define Root Dispersion to be useful/meaningful
> While statistically correct, the number is of no use and often
> deeply misleading.

The root statistics are carefull designed to extend to the reference 
clock source itself, optionally including its sources. Usually, the 
radio is considered the source, so the root delay is zero. The 
dispersion is referenced to the last update received over the radio 
channel, not the last update from the radio protocol, but not all 
drivers respect that.  In the case of the WWV driver, the delay budget 
extends to the Boulder antenna. For space use the intent is to include 
the coding delay and the lightime to the source, usually on Earth.  The 
jitter already does include the jitter of the radio measurements 
themselves, as calculated by the median filter.  For space use, this 
would include the jitter of the space link and coding/interleaving 
jitter. 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.

>
> * Fix reference identifier
> So it can handle IPv6 correctly.

This would require a real and backwards-incompatible change. We can 
discuss this at another time.

>
> * Add support for optionally transmitting timezone info to clients.
> For the chosen timezone transmit ZoneName, UTC_offset, DST start/end.

Personally, I  think this is out of scope of NTP, but I might not be the 
one to decide should the "next version" take a jink.

>
> * 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 scheme might not be what you assume. See the current 
documentation. You forgot to mention the TAI. As it stands now, the 
next-leap, leaptable-expire and TAI are already available in the kerne 
and retrievable via ntp_gettime() on all systems but Linuxl. These data 
are currently available only if Autokey is running and should be a 
separable, extendable feature.

>
>
> And that's just the ones I can remember at 11pm a saturday night...

At 0354Z on Monday morning, keep those cards and letters coming.

>
> Poul-Henning
>