[LEAPSECS] LEAPSECS Digest, Vol 51, Issue 7

[Ian Batten]

On 4 Feb 2011, at 01:01, Tony Finch wrote:


> On 3 Feb 2011, at 20:15, Warner Losh <imp at bsdimp.com> wrote:

>> 

>> Sure, we can quibble about the details.  I thought that since ntp/1588 are used in places that might not have access to the wider internet it would make sense to allow (but not require) them to distribute this information when used in environments that need this information more readily than saying 'goto http://usno.navy.gov/dut1.dat for the latest'.

> 

> There can be a standard protocol and data format, available from many URLs, private or public. I think it's reasonable to expect people running custom private installations to configure their own DUT1 servers alongside their NTP servers.


ntpv4 extensions should provide the space to insert DUT1 directly into an ntpv4 packet, shouldn't it?  It then becomes a simple configuration issue in an ntpv4 client as to whether it should set the kernel clock to the distributed UTC(?) or UTC+DUT1, and whether it should squirrel DUT1 away somewhere so that applications which want UTC on a UT1 kernel or vice versa can access the offset as well.   But if DUT1 is carried in ntpv4 extensions and provided as an option for kernel disciplined with an ntpv4 client, applications which need one time scale or the other wouldn't require modification provided the platform they ran on could run ntpv4 (and for those that couldn't, presumably it would be possible to use this service to run a carefully protected NTPv3 server that offered UT1).

ian