Messages in this thread | | | From | David Laight <> | Subject | NTP adjustments to CLOCK_MONATONIC | Date | Thu, 27 Aug 2020 14:13:21 +0000 |
| |
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)
| |