Clock_nanosleep () does not yet support CLOCK_MONOTONIC_RAW. How to deal with this?

Question

Currently clock_nanosleep with CLOCK_MONOTONIC_RAW on Debian Jessie returns EOPNOTSUPP.

How to get around the problem and compensate for possible NTP adjustments that might apply to CLOCK_MONOTONIC in a timer cycle?

Is clock_nanosleep itself a change in NTP settings? If adjustments occur during sleep, will the clock_nanosleep sleep longer than expected?

And should I even worry about the possible CLOCK_MONOTONIC NTP settings in my particular case? What would be the largest possible “time transition” applied by NTP to CLOCK_MONOTONIC, given that my code will work on the system without a real-time clock and may interrupt the Internet connection from time to time?

Long story. I use a simple loop to emulate the playback of audio files, and I need to maintain a constant playback position.

clock_nanosleep with the TIMER_ABSTIME flag seems to work fine, but I'm not sure if CLOCK_MONOTONIC is enough to avoid noticeable transitions in the playback position.

Here is the code I'm using:

 clock_gettime(CLOCK_MONOTONIC, &deadline); // run until asked to stop while(!need_quit(stop_mutex_signal)) { // do stuff ... // add time ms to previous deadline deadline.tv_nsec += device->periodTime * NANOSECONDS_PER_MILLISEC; // normalize the time to account for the second boundary if(deadline.tv_nsec >= NANOSECONDS_PER_SEC) { deadline.tv_nsec -= NANOSECONDS_PER_SEC; deadline.tv_sec++; } if(clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &deadline, NULL) != 0) { // something happened - error or exit signal, cannot continue return; } } 

I'm curious why the CLOCK_MONOTONIC_RAW support in clock_nanosleep is not yet implemented? Does this mean that CLOCK_MONOTONIC is sufficient for most cases, even for audio / video synchronization?

Answer 1

CLOCK_MONOTONIC is monotonous. It is not subject to any jumps, from ntp or otherwise. The only thing it is prone to is drift speed adjustment, which is usually done through ntpd through adjtime or similar. For short intervals, this setting will not be displayed at all. In any case, if your system is not maliciously configured, it is much more accurate than CLOCK_MONOTONIC_RAW . As an example (compiled numbers, but they are probably in the realm of reasonableness) CLOCK_MONOTONIC_RAW can run at a speed of 999950000 nanoseconds per second and CLOCK_MONOTONIC at a speed of 1000001000 nanoseconds per second.