lkml.org 
[lkml]   [2020]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectNTP adjustments to CLOCK_MONATONIC
Date
I've just noticed some strange behaviour of some code that is
comparing CLOCK_MONATONIC to a second (external) clock source.

Normally the difference is between +/-200ns in 10ms.
Which is well within the ppm errors of the crystals.

However for around 90 seconds after system boot the error
was massive - I have to force a difference of around 8000ns/10ms
to see similar behaviour.

The only explanation I can guess at is that it was subject
to NTP's maximum slew rate of 0.5ms/sec (1/2000) while NTP
was aligning CLOCK_REALTIME.

While the NTP adjustments for clock frequency drift aren't
unreasonable for CLOCK_MONATONIC, including the adjustments
for the boot time offset is rather horrid.

In this case they stopped after 90 seconds, but a bigger
offset could take hours (or even days?) to clear.

This rather breaks what timekeeping.rst says about CLOCK_MONATONIC
being useful for 'reliable timestamps and measuring short time
intervals accurately'.

Any idea what happens to CLOCK_MONATONIC over a leap second?
Its offset to CLOCK_REALTIME should really change by 1 second.

I can't use CLOCK_MONATONIC_RAW because the hrtimer code
doesn't support it.

There are also programs that need to do things (like send RTP)
every 20ms - not every 20.01ms.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

\
 
 \ /
  Last update: 2020-08-27 16:30    [W:4.427 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site