[ntp:hackers] Further to the timestamping issue
David L. Mills
mills at udel.edu
Mon Jun 16 03:56:47 UTC 2008
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.
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.
More information about the hackers