Bug 198137 - Clock Skew between clock_gettime(CLOCK_MONOTONIC) and clock_gettime(CLOCK_REALTIME) and getimeofday()
Summary: Clock Skew between clock_gettime(CLOCK_MONOTONIC) and clock_gettime(CLOCK_REA...
Status: RESOLVED DUPLICATE of bug 197299
Alias: None
Product: Timers
Classification: Unclassified
Component: Realtime Clock (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: timers_realtime-clock
Depends on:
Reported: 2017-12-11 16:33 UTC by bjascob
Modified: 2017-12-22 05:16 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.13.0-19-generic #22-Ubuntu SMP
Tree: Mainline
Regression: No

Simple timer test (1.46 KB, text/x-csrc)
2017-12-11 16:33 UTC, bjascob

Description bjascob 2017-12-11 16:33:16 UTC
Created attachment 261111 [details]
Simple timer test

While investigating audio glitches in VLC (Bugzilla ID#198075) I found that my system is reporting clock skew of about 4% between using  
   A) clock_gettime(CLOCK_MONOTONIC, &ts) and 
   B) clock_gettime(CLOCK_REALTIME, &ts) or gettimeofday(&tv, NULL)
Initially my test program shows no difference but somewhere around 30 seconds into the test the clocks diverge by about 4% and stay diverged.
This testing was done on an i9-7940x with Ubuntu 17.10 
Repeating the testing on an i870 system with Ubuntu 16.04 shows a 0% skew even after an hour of running the test.

I'd appreciate any thoughts on how to fix this (or work-around) as I suspect it is the root cause of my audio issues, although right now, I don't suspect it's causing any other problems.
Comment 1 bjascob 2017-12-11 18:08:54 UTC
I had a thought and tried disabling Ubuntu's time service (sudo systemctl stop systemd-timesyncd).  With the time service disabled the test no longer shows any difference between the clocks!  Apparently this is updating about every 30 seconds which seems ridiculously often.

Doing some tests with timesyncd off, I see a command-line "date" returning a time that is skewed about 4% relative to my accurate wall clock.  Basically I'm seeing the PC's time drift about 14 seconds every 5 minutes without the daemon running.

BTW.. Where this becomes a problem is that it looks like VLC's internal timing uses both clock_gettime(CLOCK_MONOTONIC) and pulseaudio's pa_stream_get_time.  I'm seeing a 4% skew between these and that's causing VLC to insert silences every few seconds to keep the clock's aligned. 

With timesyncd disabled I still hear the glitches and see the 4% drift in VLC (though not in my test program).  That makes me think that there are 2 very different clocks in use between pulseaudio and the rest of the OS.  Does this make any sense (separate clock from the audio chip)?

Would you suspect this is as linux issue or the motherboard?  I'd like to verify where the issue is coming from.  Is there a raw clock signal from the MB somewhere accessible (like in /proc/xxxxx) that I can look at?
Comment 2 bjascob 2017-12-11 21:10:21 UTC
I found the program "adjtimex" which seems to provide a work-around.  The following steps corrected the issue:

sudo systemctl stop systemd-timesyncd
sudo adjtimex -p

sudo adjtimex -c
-- The timing values
Comment 3 bjascob 2017-12-11 21:22:47 UTC
I found the program "adjtimex" which seems to provide a work-around.  The following steps corrected the issue:

sudo systemctl stop systemd-timesyncd
sudo adjtimex -p
** The tick parameter shows set to 10000
sudo adjtimex -c
** Shows a correct tick value of 10400 (ie.. +4% adjustment)
audo adjtimex --tick 10400
sudo adjtimex -p
** Now checking the command-line "date" to the wall clock shows no appreciable drift over a few minutes.
sudo systemctl start systemd-timesyncd

The audio glitches in VLC have also gone away.

I'm interested to hear if this is the "correct" fix.  I've never run into this issue in the past so I'm wondering if there is something that's simply incorrect in my rtc clock setup that should receive a more permanent fix or if this is common and the method I have above is how others take care of the problem.

BTW... looking at kern.log, it looks like I'm using the rtc_cmos driver registered to rtc0 (this is the only rtc listed)
Comment 4 bjascob 2017-12-22 05:15:36 UTC
Closing this issue at is it looks like the root cause has been identified and is being addressed in the following post..
Comment 5 bjascob 2017-12-22 05:16:50 UTC

*** This bug has been marked as a duplicate of bug 197299 ***

Note You need to log in before you can comment on or make changes to this bug.