[Ntp] Smearing

[Hal Murray <[e-mail]>]

> 2. Introduce some means to communicate the existence of smearing, and
> either standardising the smearing cadence or have some way of signalling
> it. Clients may be able to mix same-cadence smearing servers but cannot mix
> between smearing and non-smearing. This only legitimises the status quo
> bodge and makes it explicit. 

The problem with smearing is that the whole idea is to hide it from the 
client.  Currently, there is no way for a user program to figure out if the 
system it is running on is smearing or not.  That includes ntpd.

I think the protocol should use TAI and make available the leap info.

That means an NTP client will need to know if it should smear.

Plan A is to put that info in a flag in /etc/smear or such so that other 
programs can also use it, perhaps to unsmear or perhaps just to print a 
warning message when log files do/don't smear.

Plan B would be to put that info into the kernel.  There are spare slots in 
struct timex and struct ntptimeval.  Then a flag in ntp.conf could tell ntpd 
to smear and it could pass that to the kernel.

--------

Does a smearing client need to know anything more from a server than the 
current TAI offset and the time of the next leap?

The next leap info is big enough that I don't want it in the basic packet format.  If we put it in an extension, dumb programs will ask for it every time.  Do we want to support that?  Or perhaps, do we want to actively discourage that?

How about a new mode for inquiring about things that only change infrequently?  Is there anything besides leap info that the server might want to distribute?

--------

That brings up another issue that I haven't seen documented.  (Maybe I just forgot.)

NTPv4 has version and mode fields.  When decoding a packet, which one do I look at first?

If we look at the version field first, then we can redefine the mode field.  Or move it.


-- 
These are my opinions.  I hate spam.