Re: [time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
Ralph Aichinger wrote: > TAI would probably be the more logical way to store and do > calculations with time, only including leap seconds when > formatting time for human consumption. Indeed. Just about everybody I know who's studied this issue carefully has come to more or less the same conclusion. It would work much, much better than UTC -- except we're basically stuck with UTC. The wonderful thing about TAI is that since it's truly monotonic, it is much, much easier to represent and manipulate than is a discontinuous timescale like UTC. In fact, you can immediately see how useful a monotonic timescale is by observing that POSIX has decreed that UTC is one. Except of course that it isn't, which leads to *the* glaringly fundamental but nearly irresolvable issue when it comes to keeping truly correct time, and in particular handling leap seconds, on Unix-like operating systems. > There is a CLOCK_TAI on Linux, but what will happen if I use it > as my default clock? First of all, there's no current way of making CLOCK_TAI the "default clock". Deep down inside, the primary, master clock on any Unix or Linux system is supposed to keep UTC. When you call clock_gettime to fetch CLOCK_TAI or any of the other times, they're generally algorithmically derived from the master clock, i.e. from UTC. And even given that it's a derived clock, the support for CLOCK_TAI is, so far as I've been able to investigate it, still somewhat incomplete. When the system boots up, it has no way of knowing what the TAI-UTC offset is, so of course it starts out as 0. There's a path via which NTP or some other external program can set it, but I haven't seen an NTP server in the wild that knows how and is configured to do so. (I'd love to be proved wrong on this, though.) Furthermore, if nothing sets the TAI-UTC offset, and if a leap second occurs, the kernel blindly increments the TAI-UTC offset to 1, which is just wrong. One appealing possibility would be to redefine the kernel's master clock to be TAI, and to derive all other clocks (including CLOCK_REALTIME, which is the primary fetchable UTC time) from it. Again, the big difficulty (besides the amount of rewriting involved) is the startup sequence. There's not a good, guaranteed way for a newly-booted machine to learn what the current TAI time, and TAI-UTC offset, are. Just about every scrap of public infrastructure devoted to timekeeping distributes UTC, not TAI. (There's much more that could be said about this; I'll provide some references at the end.) And then there's the possibility of *not* rewriting any kernel code, declaring that it deals in nothing but TAI, and shoving all the squishy aspects of leap seconds and UTC conversion to user mode. But you've still got the startup problem, *and* you've got the problem that there are several places in the kernel that actually need proper UTC. One is so that you can set the modification timestamps on files correctly. And I believe there are a number of other kernel daemons and drivers that need UTC so that they can properly implement various networking protocols, such as those involved with streaming video. (I'm fuzzy on the details, but I'm reasonably sure those other kernel-level UTC consumers exist.) But if you do want to throw caution to the winds, run your kernel on TAI, and punt the UTC conversion to user mode, there's some nicely mature code already built in to every Unix and Linux system that will do most of the work for you, and it's been around since the 1990s (or maybe even the 1980s, I'm not sure). This is based on the so-called "right" timezones, which introduce the TAI-UTC offset when a conversion from time_t to struct tm is performed, i.e. at the exact same spot that timezone offsets and DST corrections are applied, which is arguably precisely the right place to do it. The requisite leap second tables are part of the zone files, the same ones that contain all of the timezone and DST information, and are regularly updated. You can read about this at: https://www.ucolick.org/~sla/leapsecs/right+gps.html (Actually, that page describes a variation on the "right" scheme, using GPS time instead of TAI.) Unfortunately, virtually no one uses the "right" zones, in part because of the boot problem, in part because of the filesystem timestamp problem, and in general because the scheme basically violates the POSIX standard up, down, and sideways. These issues have been discussed at length on, as you can imagine, the LEAPSECS and TZ lists. Here are two representative messages I had handy: https://pairlist6.pair.net/pipermail/leapsecs/2016-July/006251.html https://mm.icann.org/pipermail/tz/2004-March/012305.html ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] verifying synchronization with PPS
I wrote: > I'm guessing there are some time nuts here who might be able > to give me some pointers. And there were! Thanks for the suggestions & comments. Dana Whitlow wrote: > in the absence of a PPS or other electrical output from your > "computer", what is the nature of the time "output"? It's collecting data and coordinating activities among several other systems, each with their own clocks, some connected by serial ports and some by ethernet, some on NTP and some not, some with PPS feeds and some not, but obviously the goal is, by hook or by crook, to keep all the clocks well synchronized so that timestamped data is commensurate -- and then to positively *demonstrate* that they're well synchronized. > why not view the light output of the seconds digit with a photocell. Because I had never thought of such a thing. I could pretty easily implement, in a diagnostic window somewhere, a nice fat 1 Hz spot that would be trivial for even a crude photocell to "see". There'd be some latency, but it'd be much better than nothing. Thanks very much for the suggestion! Graham wrote: > What level of accuracy do you mean by "synchronized"? I think we'd be happy with 1 ms. > Plotting a lightly loaded Linux box, which is extracting time from > the network via timesyncd, against a GPS 1PPS signal, I observe... So it sounds like you're already doing more or less what I want to do! I'd be curious to hear more about the setup you use to make those plots. > The owner of this list has designed an excellent dual input timing > device called the TICC, which can compare two PPS signals... Ha! Thought so. Thanks for the pointer. David Taylor wrote: > Folkert van Heusden has a driver for NTP which includes PPS output: > https://vanheusden.com/time/rpi_gpio_ntp/ Great! I will read that. Hal Murray wrote: > There is code in the Linux kernel to generate a PPS output. Huh! I should have noticed that. (I'd been thinking of adding it, if I had to.) > I think it uses the printer port... But it shouldn't be too hard to modify it to use a GPIO pin. > If I wanted to try something, I would write a user-level hack > to flap a modem line and compare that to a PPS signal. That would probably be fine for my current purposes. The latent time-nut in me worries about scheduling and latency and jitter, of course, tempting me to chase an overkill solution which is not only in the kernel, but implemented in a brute-force, special- cased way, eschewing the extra function calls and indirections (and hence latency) which a properly general-purpose solution might involve. Thanks again for all the replies; this has been very helpful. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] verifying synchronization with PPS
This is a different sort of question than what seems to be discussed here usually, and I apologize if it's wholly off-topic, but I'm guessing there are some time nuts here who might be able to give me some pointers. If I have two boxes with clocks that are supposed to be perfectly synchronized, and I need to verify this, and they're physically right next to each other, and they both have PPS outputs, one way to verify the synchronization would be to compare the two PPS outputs with a 'scope. (I'm guessing there's probably a dedicated instrument out there specialized for the task of comparing two such PPS signals for frequency, phase and jitter, and if I were a proper time nut myself I guess I'd know that.) My specific question concerns the case that one of the boxes is a computer, for example, a Linux box with time kept using ntpd or chrony (perhaps also listening to a PPS signal coming in on a serial port). But I've never seen a computer with a PPS *output*. Is this a reasonable thing to be thinking about, or am I going about it wrong? How would *you* positively verify synchronization of such a system? Me, I'm pursuing this idea because too much of the time (at least in my own, perhaps parochial experience) synchronization seems to be "verified" either by saying "Yes, we configured it properly", or by observing a status output from ntpd or chrony claiming the requisite synchronization has been achieved, but in neither case by making a definitive, independent, external, empirical determination. (Perhaps PPS is overkill for this situation; perhaps it's the case that given the inherent inaccuracies of software-based timekeeping, a software-based query mechanism -- perhaps using ordinary NTP or PTP protocols -- would be sufficient for externally assessing synchronization.) I guess it's not a *completely* unreasonable thing to be thinking about, because I've found a couple of web pages (for example https://www.raspberrypi.org/forums/viewtopic.php?t=115554 and https://github.com/jsln/pps-gen-gpio) describing how to implement a PPS output under Linux. And I do realize that trying to minimize the jitter and latency in this situation (given that the principal drivers for the hypothetical output are inherently software-based) presents considerable difficulties. But taking all of that into consideration, I'm wondering what others think of the approach. Thanks for any comments. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
