NTP adjustments to CLOCK_MONATONIC

[David Laight <David.Laight@ACULAB.COM>]

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)