[LEAPSECS] UT1 via NTP

[Martin Burnicki]

Rob Seaman wrote:
> One uses the tools as designed for diverse purposes. NTP in a pool
> environment is accurate to a few milliseconds. With our local GNSS
> references something better than a millisecond. With an IRIG shared
> memory reference maybe an order of magnitude better. Hardware time
> capture for our Meinberg IRIG PCIe cards is spec'ed and measured to 5
> microseconds. The PTP versions of those cards quotes something better
> than 1 microsecond. Hardware time capture to OCXO in the Meinberg M1000
> should be precise / accurate to 100 nanoseconds. All of these are
> commercially available with only ordinary attention to metrology, e.g.,
> like understanding the calibration of a precision balance in a lab.
> Meinberg has an excellent monitoring tool built in to their reference
> clocks.
> 
> "Customers" (internal or external) for astronomical timekeeping (but
> should be applicable to other fields) may require TAI, GPS, UTC, UT1, or
> more esoteric things like TT. I can set the Meinberg references to
> deliver all of these except UT1. All the rest would follow. I'd be happy
> to hear about support from other vendors. Needless to say, commercial
> timekeeping vendors should also be expected to implement conforming leap
> second support for their internet attached devices.

ntpd has already built-in support for leap second smearing. This means,
it anyway reads a leap second file as provided by NIST or IERS, checks
automatically if a new file version is available, and then optionally
applies a smearing offset to the time sent to its clients, if configured
to do so. The internal system time would still be UTC, though.

Similarly, it shouldn't be too hard to add some support to read a DUT1
file, and apply the DUT1 offset to the time sent to clients. So you
could easily set up your own UT1 server.

However, similar to the leapsecond file, it has to be made sure that the
DUT1 file is updated as necessary. This could be done automatically by
scripts / wget / curl, similar as it's done with the leap second file.

Of course it would be possible to set up an extra DUT1 server, as Hal
has suggested, but then each client had to get UTC from one source, the
DUT1 offset from another source, and put things together.

A manual or automatic feed of the DUT1 numbers would be required in both
cases, so which approach is to be preferred depends on the accuracy and
other requirements of the tasks that have to be solved.

Martin