CLOCK_REALTIME nanosecond precision support in kernel

Question

I wrote a simple program to determine if i can get nanosecond precision on my system, which is a RHEL 5.5 VM (kernel 2.6.18-194).

// cc -g -Wall ntime.c -o ntime -lrt
#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char* argv[])  {
    struct timespec spec;

    printf("CLOCK_REALTIME - \"Systemwide realtime clock.\":\n");
    clock_getres(CLOCK_REALTIME, &spec);
    printf("\tprecision: %ldns\n", spec.tv_nsec);
    clock_gettime(CLOCK_REALTIME, &spec);
    printf("\tvalue    : %010ld.%-ld\n", spec.tv_sec, spec.tv_nsec);

    printf("CLOCK_MONOTONIC - \"Represents monotonic time. Cannot be set.\":\n");
    clock_getres(CLOCK_MONOTONIC, &spec);
    printf("\tprecision: %ldns\n", spec.tv_nsec);
    clock_gettime(CLOCK_MONOTONIC, &spec);
    printf("\tvalue    : %010ld.%-ld\n", spec.tv_sec, spec.tv_nsec);

    return 0;
}

A sample output:

CLOCK_REALTIME - "Systemwide realtime clock.":
        precision: 999848ns
        value    : 1504781052.328111000
CLOCK_MONOTONIC - "Represents monotonic time. Cannot be set.":
        precision: 999848ns
        value    : 0026159205.299686941

So REALTIME gives me the local time and MONOTONIC the system's uptime. Both clocks seem to have a μs precision (999848ns ≅ 1ms), even though MONOTONIC outputs in nanoseconds, which is confusing.

man clock_gettime states:

CLOCK_REALTIME_HR High resolution version of CLOCK_REALTIME.

However, grep -R CLOCK_REALTIME_HR /usr/include/ | wc -l returns 0 and trying to compile results in error: ‘CLOCK_REALTIME_HR’ undeclared (first use in this function).

I was trying to determine if i could get the local time in nanosecond precision, but either my code has a bug or maybe this feature isn't entirely supported in 5.5 (or the VM's HPET is off, or something else).

Can i get local time in nanoseconds in this system? What am i doing wrong?

EDIT

Well the answer seems to be No.

While nanosecond precision can be achieved, the system doesn't guarantee nanosecond accuracy in this scenario (here's a clear answer on the difference rather than a rant). Typical COTS hardware doesn't really handle it (another answer in the right direction).

I'm still curious as to why do the clocks report the same clock_getres resolution yet MONOTONIC yields what seems to be nanosecond values while REALTIME yields microseconds.

You hardly get microsecond precision in Linux, definitively not nanoseconds! Maybe you confuse precision and resolution? **Very** different things! And that smells strongly like an XY problem. Why do you want to get ns resolution at all? — too honest for this site, Sep 07 '17 at 11:13
'Can i get local time in nanoseconds in this system?' Where in the system? Moving such a value about, (eg. returning it from a kernel call), would render it stale. — Martin James, Sep 07 '17 at 11:18
@Olaf i was checking if a business requirement could be met (without delving into hard real time systems) and surpassed. Timestamping etc. — vesperto, Sep 07 '17 at 12:42
@MartinJames point taken. In this case, as long as the time delay is the same, there shouldn't be a problem. — vesperto, Sep 07 '17 at 12:43
Does anyone know when did the kernel start to support nanosecond precision? And/Or is this distro-related? — vesperto, Sep 07 '17 at 12:45
Your question still does not make any sense. Did you even read my comment completely? Did you understand the differences? Did you use a proper translation tool? If you need ns **precision**, no current realtime system will guarantee this. even a hardware implementation in an FPGA would have to struggle hard, depoending on the actual problem. — too honest for this site, Sep 07 '17 at 12:47
999848ns is about 1 millisecond (msec), not 1 microsecond (μsec). — stark, Sep 07 '17 at 14:26

score 0 · Answer 1 · edited Sep 07 '17 at 12:48

0

RHEL5 is really ancient at this point, you should consider upgrading. On a newer system (Ubuntu 16.04) your program produces:

CLOCK_REALTIME - "Systemwide realtime clock.":
    precision: 1ns
    value    : 1504783164.686220185
CLOCK_MONOTONIC - "Represents monotonic time. Cannot be set.":
    precision: 1ns
    value    : 0000537257.257923964

edited Sep 07 '17 at 12:48

gsamaras

71,951
46
188
305

answered Sep 07 '17 at 11:20

janneb

36,249
2
81
97

Clock resolution depends on the hardware. These days, frequently a timer in the CPU. – stark Sep 07 '17 at 14:28

CLOCK_REALTIME nanosecond precision support in kernel

1 Answers1

Linked