[LEAPSECS] Running on TAI

[Rob Seaman]

Hi Hal,

Again, it doesn't appear that the current discussion has anything to do
with astronomical use cases.


>> The trick is to find a source that will set a POSIX system to TAI, and then
>> to avoid the gotchas that happen when such a system interacts with other
>> POSIX systems. 
> What do the systems that point telescopes use for maintaining their system 
> clock?  Do they use NTP or a special program that listens to GPS or a local 
> Hydrogen maser or ...?
Radio telescopes (or LIGO, for instance) may have extremely high
precision requirements (and thus fancy clocks), at least as much for
frequency as time. Most other telescopes need accurate time more than
high precision time. Telescopes tend to be in remote locations
(mountains, Antarctica, in orbit, etc) and generally rely on GNSS
clocks. These vary in quality according to the observatory budget. NTP
is used across whatever mountaintop network is deployed, but may be
poorly behaved across microwave links to remote campus pools, for instance.

> Some GPSDOs have the option to return GPS time rather than UTC.

Our Meinberg ref clocks can deliver GPS, UTC, or TAI (and thus other
derived timescales).


> GPS is a fixed offset from TAI. So it's easy to run your system on TAI. All it takes is a little sysadmin hacking, no programming.
Yes, but there may be significant operational details, e.g., we have red
clocks for UTC in our control rooms and white clocks for local time, but
might want green for TAI or so forth. There are a lot of potential
timekeeping requirements depending on the science and logistics.

> You won't easily get redundancy from checking with other NTP servers.  If you 
> have several friends running similar systems, you could set up a private NTP 
> network.
We operate four telescopes currently on two mountaintops. Three GNSS
clocks (one campus spare) plus a couple of IRIG-driven linux kernel
implemented stratum-0 ref clocks per telescope provide plenty of NTP
stratum-1 references. Don't know about a private NTP network, the campus
stratum-2 pool clocks generally don't get given the time of day, so to
speak, but we want something remote for fail-over. (Would have to be a
pretty intrusive local network event to get there.)

> With some work it would be reasonable to setup a ntp server that took in UTC 
> but gave out TAI.  That would be similar to the way leap smearing works.  We 
> could use a separate port number to minimize confuzion.
Also, NIST has a UT1 reference, but I for one haven't had luck connecting.


> As far as I know, the kernel doesn't know anything about what type of time it 
> is maintaining.  It just sets the clock as directed and goes tick, tick, tick. 
>  The trouble is with the time conversion routines.  They all assume a time_t 
> is UTC.  So if you ran your system on TAI, all your log files would be off by 
> 37 seconds.
"Off" from what? If the system is set to GPS, TAI, UT1 or whatever, the
log files arguably should be as well.

> How hard would it be to insert a wrapper in front of the time conversion 
> routines?  The idea is to rename all the current time conversion routines from 
> foo to foo_utc and implement foo_tai that concerts between UTC and TAI.  It 
> would need a list of leap seconds.  The default implementation of foo would 
> call foo_utc but an environment variable or such would switch to using foo_tai.

Or use Steve's TZ-based solution.

Rob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190115/84a55938/attachment.html>