2

For our project, we would like to have all servers and systems synchronised to a linear time reference (without leap second).

Therefore, we would discard UTC but are very interested in advertising TAI time (or GPS time).

Our time server will be connected to an atomic clock (or possibly a GPS receiver).

Is NTP suitable to advertise TAI or GPS time? If yes how to configure it?

Should we use other protocol to advertise such time?

Final note: AFAIK there is no TAI or GPS time configurable for the Linux kernel. I guess our best option is to "fake" it by configuring the kernel time to be UTC and providing it a TAI or GPS time instead. Or is there a better alternative?

Huygens
  • 1,678
  • 2
  • 19
  • 36
  • 1
    It should be possible to configure your own timezone without any corrections into the [tzdata](http://en.wikipedia.org/wiki/Tzdata) database and to feed the GPS time without UTC offset into `ntpd`. – Sven Mar 18 '14 at 09:10
  • That one solution I would try to "hack", do you know of anyone who has successfully implemented this? Documentation is scarse on this subject, and I did not find clear information that I can feed GPS time to ntpd just like if it was UTC. – Huygens Mar 18 '14 at 21:50

2 Answers2

2

According to the NTP project's page on the subject, you're going about this the wrong way. UTC is pretty heavily embedded as an assumption in NTP, but "right" timezone files are generally available - my desktop, which is Fedora 20, has them as a standard part of the tzdata package, in /usr/share/zoneinfo/right/.

Instead of trying to get NTP to keep the clock sync'ed to a non-UTC standard, let NTP keep the clock sync'ed in UTC, and have the system take its standard timezone from a TAI-compliant timezone file, to express this time in TAI for all requesting applications.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • I had thought of that but this solution has the following drawbacks: the systems are subject to the leap seconds and the systems needs to be regularly updated to get the right offset in tzdata. Due to many requirements (which I haven't yet all analysed) these might not be "acceptable"/"feasible". :-( Note that NTP is not mandated, so if another protocol can be used and better suited then that would be perfect (thinking of PTP, but unsure about its maturity) – Huygens Mar 18 '14 at 21:48
  • I am not sure about the "right" set of timezones. Those are based on TAI-10 (so actually the difference between the right/UTC and UTC is 25 sec instead of 35 sec nowadays). To me it means that the kernel internal clock and the hardware clock would still be UTC, but that date/time displayed by user space tool (such as the command `date`) would display the TAI-10 time. In my understanding, it means that during a leap second, the kernel will still change its internal clock. And the offset which `date` is using will be updated. – Huygens Mar 20 '14 at 15:53
  • The kernel's internal clock is in elapsed seconds since the epoch; all conversion, including to UTC, is done by TZ files. The hardware clock I can't speak about, since it depends on the hardware. – MadHatter Mar 20 '14 at 15:59
  • You're misinformed, MadHatter. UTC time is not monotonic, and the UNIX time_t value is not the actual number of atomic seconds since January 1st, 1970 at 00:00:00 UTC, but the number of _non-leap_ seconds. Every time there's a leap second inserted, the time_t value repeats: 23:59:60 and 00:00:00 the next day convert to the same time_t value even though they're a second of real time apart. TAI is monotonic with no repeated values, which is why it makes more sense as the basis for computer time. – Mark Reed Jun 30 '21 at 00:40
  • @MarkReed strictly speaking, UTC time is monotonic, because there hasn't yet been a negative leap second; but I take your point. I accept the above sentence should start "*The kernel's internal clock is in elapsed seconds since the epoch, not counting leap seconds,*", but I stand by the rest of it. – MadHatter Jun 30 '21 at 06:16
  • The other way around, @MadHatter. Since 23:59:60 and 00:00:00 are represented by the same timestamp value, if your system time has subsecond resolution, then the entire second between those two values consists of timestamps that are then repeated a second later after a jump backward of a second at the 00:00:00 mark, unless you adopt a smearing strategy like Google etc. A negative leap second, if we ever had one, would actually maintain monotonicity; the 1-second leap forward from 23:58:58 to 00:00:00 would skip a second's worth of timestamps but not repeat any. – Mark Reed Jun 30 '21 at 12:20
  • @MarkReed all fascinating, but I'm not sure what point you're making *about what I said*, and in any case I don't think we should continue the discussion here If you think you have light to shed on the question as a whole, I encourage you to write an answer of your own. – MadHatter Jun 30 '21 at 16:07
1

You can create your own time standard on an isolated network that you control. This is a little kludgy. In order for this to work you must have all of your machines configured to only synch with the time servers you control. I have provided four possibilities. I think your best bet is the first or second depending on how strict your time constraints.

Remember for all of the following options you need to ensure that the server does not have a leap file and that none of the computers ask the outside world for the time.

  1. ntpd reference implementation with Undiciplined Local Clock (Recommended/Easiest):

    If you want to have an ntp server serve a time different from UTC this is pretty easy. Set the hardware/kernel clock to whatever faketime you need. Then configure ntpd to use the Undisciplined Local Clock driver (127.127.1.x) and no external clocks. The ntp server will happily chug along and serve the local clock. The one problem is that since you are using the local clock driver the time will not be stable and will drift milliseconds one way or the other because that quartz crystal is no rubidium reference. If you need the faketime and stability; you need to use the option #2.

  2. ntpd reference implementation w/ ULC and PPS source (Recommended/Stability):

    Use the ULC described above and add a PPS source. Once you add the PPS source you will need to add the prefer keyword for the ULC entry in ntp.conf. This will mean that the server's clock is kept stable because the PPS source ticks off each second for you.

  3. ntpd reference implementation with External Clock Discipline and the Local Clock Driver (Complicated):

    This is still a solution that relies on using the ntpd reference implementation but I am not very familiar with it. All I can do is give you the link to more details: http://www.eecis.udel.edu/~mills/ntp/html/extern.html

  4. Jans - third party ntp testing tool (easier than #3 but unknown entity)

    I have no experience with this product but I know of it from the ntp mailing list. It will allow you to server faketime but it does none of the clock discipline like the reference implementation. More info: http://www.vanheusden.com/time/jans/

dfc
  • 1,331
  • 8
  • 16
  • I think we will use your second option with the PPS. It is possible to recevier via RS-232 NMEA strings from the GPS receiver, which will allow us the synchronise the internal OS clock to GPS time. And then PPS will keep the time accurately enough for our needs. Thank you for the answer. – Huygens Apr 04 '14 at 08:54