[ntpwg] Further to the timestamping issue

[David L. Mills]

Warner,

M. Warner Losh wrote:

> picking a random email to reply to...
>
> The problems that I've had with leapseconds:
>
> (1) ntpd only advertises them a day in advance, which means brief
> outages can miss them.


Not quite true. When from the leapseconds file or autokey, the warnings 
are indefinate. True, the server leap bits are set only on the day, so 
if no other source was available than a reference clock with radio bits, 
the server would not show those bits other than the day of the leap.

> (2) IRIG signals them only an hour in advance, which is too slow to
> drive ntpd from.

No IRIG format I am aware of has provisions for leap warning.

> (3) There's no way to get the current offset easily from ntp servers
> since so few of them have the crypto setup to get the
> leapsecond.txt file. This is especially true in "sensitive"
> networks with no connectivity to the internet.

The only thing necessary to get the TAI offset is the kernel 
ntp_gettime() syscall, which Linux does not have at present. The autokey 
is necessary only to download the leapsecond values from a server/peer. 
That's a crock and should be changed. The leapseconds table itself is 
loaded even without autokey.

> (4) Machines off for a long time require a long time to get what the
> current UTC/TAI offset is. GPS is good and can give the current
> offset, but there's no mechanism to get the intermediate values.
> Not totally critical, but customers notice when the historical
> leap seconds we made up in this case are wrong.... This is the
> 'cold spare' problem...

By :intermediate values" I assume you mean the historic leapseconds 
table, which is available via FTP from NIST. I submit this is not an 
issue with NTP; the issue should be owned by the timezone folks, who 
should also show leapsecond warning and TAI offset available from IERS. 
Another possiblity is SNMP.

>
> These issues can be worked around, but they are all a pita.
>
> Warner