A Twisty Maze of Linux Clocks, All Slightly Different | Hacker News Reader

A Twisty Maze of Linux Clocks, All Slightly Different

geekwhisperer.blogspot.co.uk

105 pointsjrepin25 comments

While the article in general is great, the author’s assumption of one true time is rather cute :).

At the very least, there are:

- the actual number of seconds that passed since the epoch, i.e. the number a perfect egg timer would show if you had set it off at 12 AM on 1970-01-01.

- International Atomic Time (IAT), the closest thing to the aforementioned egg timer we currently have (though with some offset, naturally).

- Terrestrial Time (TT), which is 32.odd seconds ahead of IAT, apparently for historical reasons.

- Universial Time (UT<timezoneoffset>), which is supposed to be the solar time at one particular location, Greenwhich for UT1.

- Coordinated Universal Time (UTC), probably the closest thing to The One True Time, which jumps around merrily depending on the rotational speed of Earth, trying to keep days of 86400 SI seconds.

Oh, and we’re not even considering relativistic effects here.

I would actually say that "perfect egg timer" time is the closest thing to The One True Time, if such a thing were actually possible (of course it isn't, due to the relativistic effects you mention).

Well, yes, but the author equated (in my reading) The One True Time with the wall time/time provided by NTP and such, which clearly jumps around and is UTC.

The ‘perfect egg timer’ is, if anything, comparable to the monotonic clocks.

The usual acronym for International Atomic Time is TAI (Temps Atomique International)

Apologies & thanks for the heads-up! :)

This bit makes me wonder about the entropy of the nanosecond clock, for adding entropy to an PRNG:

> Given scheduling jitter and so forth, it's not clear what it means to get a timestamp with nanosecond resolution from the operating system. It probably takes thousands, if not millions, of instructions between the time the timestamp is retrieved and the time your program looks at it

You don't have nanosecond entropy, but you do have microsecond entropy.

Plus if it really does tick off in nanoseconds you'll get some random nanosecond number, which you can't use for scheduling, but will be good to feed to the PRNG.

I can definitely see some uses here as long as between calls they are monotonically increasing and ordering from two sets of system calls is correct (so a call that started earlier will get an earlier timestamp as a result of the call).

The difference would be along the lines of lag vs precision. Measuring time in a non-hard-realtime operating system is a hairy proposition in the best of cases, after all you don't know how long your thread slept right after completing the system call but before your application got to do useful work. Usually this is only microseconds but it isn't rare at all to see this value have extremely high upper limits (100's of milliseconds or more...). This depends a lot on how many cores you have and the quality of the device drivers as well as which scheduler you run.

Note that some clock reads that appear to go through a file system actually don't on some architectures. On x86-64, there's a special page that's mapped read only for all processes. This page includes time data that is updated by the kernel. When you call the glibc syscall wrapper to get the time, it doesn't actually invoke a syscall; instead, it just reads the correct bit of data from that page. I don't know if that applies to nanosecond resolution clocks though....

That would be the _COARSE clocks the article mentions... It would obviously not have nanosecond resolution - for that it would have to be updated by the kernel every nanosecond.

Most operating systems create a vdso with user space accessable operations such as getting time, etc

This article is: 1. Useful 2. Interesting 3. Actually has comments from people on the internet trying to get information in a polite and well explained manner. (WHAT?!)

It gets even more interesting when you put the machine into suspend, and time starts passing without timer interrupts getting serviced.

Or when NTP notices that your local clock is drifting, and attempts to discipline it.

As they say on the time-nuts listserv: A man with one clock always knows what time it is. A man with two clocks is never quite sure...

From 2010 but still interesting. Time an programming are inexorably intertwined, either by the time to do something is short enough, or the time when to do something is accurate enough. Having done some real time work (trying to get Linux running a robot back in the day) it was amazing at how challenging it was to keep things in sync. Given the cheapness of transistors there are a bazillion timers and clocks in ARM chips. At some point I expect to see a dedicated small core which does nothing but manage the observation of, and reporting on, the passage of time.

Is quite worth to read this : http://en.wikipedia.org/wiki/Clock_signal . You don't need a special core for this, the whole processor is a giant clock distribution platform to different areas (cores/regions).

Even the brain has some neurons linked together that produces a kind of "clock", that is, a pulse that is circulary propagated via the participant neurons. For example the alpha wave. However, is not sure if this is linked to how we perceive time intervals.

So let's say I want easy cross-platform access to a monotonic timer which gives me the number of egg timer (to use the phrase here) milliseconds since a certain UTC time. Assume that I've got an NTP server available to keep me somewhat near atomic reality, and let's neglect relativistic shenanigans. Is there such a function call?

Is clock_gettime() what you're looking for (specified in POSIX)?

Although, in one embedded program of mine, when I run it fast enough it spends more time inside of clock_gettime() measuring itself than it does actually running.

http://man.cx/clock_gettime

Thanks nitrogen for the link. Maybe it is, but I'm not experienced enough with time issues to know. I'm wondering what happens when your PC's crystal is a few percent slow or fast, and an NTP client applies corrections. Sure, it stays monotonic (with CLOCK_MONOTONIC), but what happens beyond that? And, is there equivalent functionality available on Windows?

It's not true that if you pass a pointer to a 'struct timezone' to gettimeofday() it just gets filled with zeroes - the tz_minuteswest field is filled with the current local timezone offset (based either on the TZ environment variable or on /etc/localtime).

If you think it's complicated in Linux, just try writing a mobile drag racing game for Windows 8.

If you try to index a GPS trace of a car driving the quarter mile by the system clock, good luck, because you can experience astonishing precision without accuracy.

I'm sad the newer time functions are still "esoteric"—it's the only sane POSIX timer API I'm aware of, but it's not available on Mac OS X or FreeBSD the last I checked.

Can't forget about CLOCK_MONOTONIC_RAW in addition add to CLOCK_MONOTONIC

I wrote a blog post about clocks and timers earlier: http://www.club.cc.cmu.edu/~cmccabe/blog_time_and_time_again...

It gets especially interesting when you start thinking about mutexes and condition variables with timeouts.

This looks like an answer to my question I posted elsewhere under this story. (Namely, how do I get egg-timer elapsed time since a certain UTC time? Which, the UTC component isn't a must have for me, the Unix Epoch will work just as well.)

But I notice that your solution is POSIX only. How about Windows?

And how do NTP adjustments affect this solution -- surely when the NTP server tells you your system clock is consistently off by 16%, there's got to be some effect on clock_gettime with CLOCK_MONOTONIC, right? I'd like to retain the ability to use NTP to improve the accuracy of the results.

CLOCK_MONOTONIC is affected by NTP on Linux, at least.

UNIX time is not actually seconds since the epoch. It's just something very, very close. There are a few cases where the same time_t value repeats for two seconds in order to insert a leap second.

With regard to Windows, I assume there are equivalents to all these interfaces, but I don't know what they are.

Reply on news.ycombinator.com