Bug 198137
| Summary: | Clock Skew between clock_gettime(CLOCK_MONOTONIC) and clock_gettime(CLOCK_REALTIME) and getimeofday() | ||
|---|---|---|---|
| Product: | Timers | Reporter: | bjascob |
| Component: | Realtime Clock | Assignee: | timers_realtime-clock |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bjascob |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 4.13.0-19-generic #22-Ubuntu SMP | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | Simple timer test | ||
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? 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 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) Closing this issue at is it looks like the root cause has been identified and is being addressed in the following post.. https://bugzilla.kernel.org/show_bug.cgi?id=197299 *** This bug has been marked as a duplicate of bug 197299 *** |
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.