About time in linux system

xtricman · 2018-05-13 05:31:52

I learned that some machines have a hardware called RTC powered by a battery so it keep time going even when the machine is poweroff.
Linux kernel read time from RTC as an initial value at boot then keep time going using CPU ability and ignores RTC hardware.

Then I read some document at clock_gettime, so I'm wondering, how many system-wide clocks are there in the linux kernel, why we got

CLOCK_REALTIME, CLOCK_REALTIME_COARSE,CLOCK_MONOTONIC,CLOCK_MONOTONIC_COARSE,CLOCK_MONOTONIC_RAW,CLOCK_BOOTTIME

so many clocks?

When NTP client like systemd-timesyncd is running, which clock is it setting?
What about command line tools like date ,hwclock or some process calling settimeofday or adjtime?
How does it interprete

struct timespec

structure, does it see this struct as UTC or local time?

How does the kernel interprete time in RTC hardware(UTC or local time) when booted(userspace settings clearly doesn't apply to the booting stage) ?
How does the kernel initialize all these clocks?

seth · 2018-05-13 08:10:54

This has nothing to do with "linux".
You're conflating times, timezones, clocks, clock generators, strcutures, functions and apparently don't know what "coarse" or "monotonic" mean.

https://en.wikipedia.org/wiki/Monotonic_function
https://en.wiktionary.org/wiki/coarse

If this is a generic query for knowledge, start with a dictionary and afterwards reading eg. https://wiki.archlinux.org/index.php/Time to understand at least the very basics to make informed questions.
If you've an actual problem you want to be solved, ask about that particular problem.

The timespec strcut is just a structure of numbers, it could hold your birthday ab urbe condita or the actual time in china.

man 3 timespec
man 2 gettimeofday

mpan · 2018-05-13 08:40:09

xtricman:
There are two separate concepts present here: actual timekeeping and abstract terms used to acquire timestamps.

Let’s start from the latter. Historically, the time¹ function was used for acquiring a timestamp. The issue is that time is ill-defined: its output is actually meaningless if you think deeply about what it signifies. What’s the relationship between two timestamps obtained from time? Do two calls to time from different processes yield values that are somehow related? What about time adjustments? What granularity? Can time move backward? time is fine for obtaining coarse “human” time for displaying in simple programs, but fails to meet requirements for being used to work with time.

The answer is clock_gettime². It allows a program to request a timestamp with explicitly specified, well-defined characteristics. These characteristics are expressed using abstract terms: a clock that never moves back (is monotonic, but with no specific reference point), a system-wide clock that is shared across all processes and tries to follow actual time (realtime) and so on. clock_gettime is told what to return using a clock identifier. POSIX defined two predefined identifiers: CLOCK_MONOTONIC and CLOCK_REALTIME.

Implementations may provide additional timestamp characteristics and Linux does that. Some of them are meant to address particular issues: like CLOCK_BOOTTIME which is like CLOCK_MONOTONIC, but tries to follow time covered by CLOCK_REALTIME quite closely, including times when the system is suspended and not measuring time. Or *_COARSE clocks that are meant to be cheaper to access on the expense than their non-coarse counterparts. There are also some sources that are thrown in “just because they are available”: CLOCK_PROCESS_CPUTIME_ID is an example. It doesn’t really solve any time-related problem, but since processes have their own time measurement… why not expose it to the userspace?

And this is about acquiring time³. It’s an abstract API to be used. How a system implements that under the hood is a different matter, which is not covered by specification of the clock_* functions. However, just to not keep part of the topic uncovered, Linux sees [at least] two clocks. There is a hardware RTC clock, which keeps time all the time, even if the computer is off. The system may access it, but it would be relatively expensive to do that all the time. It would also make time adjustments harder. So the kernel keeps its own timer, which is incremented when interrupts from RTC are delivered to the CPU. This time is cheap to access and can be freely adjusted (for example with NTP). The system does timekeeping in many other places too: for example clocks measuring time used by each process.

The interpretation of the value stored in a timespec structure depends on how it has been obtained and how it is to be used. It’s not even expressing point of time, but a time period — and therefore the mere question of it being UTC or local bears no sense, because periods are not affected by time zones. “4 hours passed” will be the same in UTC as in any other time zone; it will be the same on the Moon too, and near Alpha Centauri, assuming the same definition of hour.
____
¹ ISO 9899:2011 7.27.2.4; time() in POSIX; time() on cppreference.
² clock_gettime() in POSIX
³ Or setting time, but this is not the point of this discussion.

Last edited by mpan (2018-05-13 09:21:34)

Cody Learner · 2018-05-13 19:23:26

I feel compelled in this case, to express some gratitude towards seth and mpan. I feel it's deserved. As I see it, this is a good example of going well beyond simply being helpful. Thanks to both of you for sharing your knowledge, providing sources, and the very detailed explanation.

Arch Linux

#1 2018-05-13 05:31:52

About time in linux system

#2 2018-05-13 08:10:54

Re: About time in linux system

#3 2018-05-13 08:40:09

Re: About time in linux system

#4 2018-05-13 19:23:26

Re: About time in linux system

Board footer