6

The output of cat /sys/devices/system/clocksource/clocksource0/available_clocksource lists the available hardware clocks.

I have changed the clocks, without any visible difference. sudo /bin/sh -c 'echo acpi_pm > current_clocksource'

What are the practical implications of changing the hardware clock? Is there a way to check the resolutions (or some other visible change) of the available clocks?

TheMeaningfulEngineer
  • 5,735
  • 15
  • 64
  • 113
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/2/html/Realtime_Reference_Guide/chap-Realtime_Reference_Guide-Timestamping.html may or may not be helpful. –  Oct 28 '14 at 18:24

2 Answers2

9

Well, first of all, the kernel chooses the best one automatically, it is usually TSC if it's available, because it's kept by the cpu and it's very fast (RDTSC and reading EDX:EAX).

But that wasn't always the case, in the early days when the SMP systems were mostly built with several discrete cpus it was very important that the cpus where as "equal" as it was possible (perfect match of model, speed and stepping), but even then it sometimes occurred that one was sightly faster that the other, so the TSC counter between then was "unstable", that was the reason to allow to change it (or disable it with the "notsc" kernel parameter). And even with this restrictions the TSC is still the best source, but the kernel has to take great care to only rely on one cpu in multicore systems or actively try to keep them synchronized, and also take in account things like suspend/resume (it resets the counter) and cpu frequency scaling (affects TSC in some cpu models).

Some people in those early days of SMP even built systems with cpus of different speeds (kind of the new BIG.little architecture in arm), that created big problems in the timekeeping area.

As for a way to check the resolutions you have clock_getres() and you have an example here.

And a couple of extra links: oficial kernel doc (there are other interesting files in this dir) and TSC resynchronization in chromebooks with some benchmarks of different clocksources.

In short, there shouldn't be any userspace visible changes when changing the clocksource, only a slower gettimeofday().

Jorge Nerín
  • 940
  • 5
  • 5
  • In the example you gave, I would say that changing the `current_clocksource` would influence which timer is counting the `CLOCK_MONOTONIC`? Also, in the example they all have the same frequency. Shouldn't `tsc` be faster than the other two? – TheMeaningfulEngineer Nov 03 '14 at 17:43
  • 3
    TSC is faster to read. Picture it like if you have two clocks, with a resolution of one minute, but to read one you spend half a second, but to read the other one you spend 20 seconds. Frequency ≠ read speed. – Jorge Nerín Nov 03 '14 at 21:43
2

The Hardware Clock is a clock that runs independently of any control program running in the CPU and even when the machine is powered off.

The System Time is the time kept by a clock inside the Linux kernel.

Some programs and fringe parts of the Linux kernel such as filesystems use the kernel timezone value. An example is the vfat filesystem. If the kernel timezone value is wrong, the vfat filesystem will report and set the wrong timestamps on files.

You can use hwclock command to view the hardware clock time with: hwclock --show

You can also sync the system time to the hardware clock time, and vice versa, using --systohc and --hctosys flags respectively.

Baazigar
  • 732
  • 3
  • 9