Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in mono-raw base. | Date | Tue, 23 Apr 2024 09:22:06 +0000 |
| |
From: Thomas Gleixner > Sent: 23 April 2024 01:25 ... > >> It really would be nice if those big adjustments didn't affect > >> CLOCK_MONATONIC. (as an example try sending RTP audio every 20ms) > > They don't affect CLOCK_MONATONIC at all because there is no such clock :) > > > Hmm, probably this is out of context for this patch and probably a > > question for the time maintainers / experts? > > The quantity of the initial frequency adjustments depends on the > accuracy of the initial clock frequency calibration which is on most > sane systems within +/- 500ppm. > > 500ppm of 20ms == 10us > > If the clock calibration is off by a larger margin then that needs to be > fixed.
The initial adjustment depends on the accuracy of the initial RTC value read from the local hardware. This is unlikely to be more accurate than 1 second and can easily be a few seconds out.
Correcting this causes NTP to adjust the clock at its maximum drift rate for a while - I'm sure I've seen this happen for minutes. Once this completes there is a 'step change' in the frequency adjustment.
Once the system has been running for a while the adjustments are minor. Time runs alternately fast and slow to maintain long term accuracy.
This is noticeable if you use schedule_hrtimeout_range(,, HRTIMER_MODE_ABS) to synchronize to an accurate external clock [1]. (Without NTP it has to adjust for temperature changing the frequency.)
David
[1] Imagine some hardware that counts usecs after the 1-second GPS pulse. and a driver that adjusts a sleep to wake up when that count is between (say) 400 and 600. Using a timer and a single readl() is far faster than taking an interrupt. (In our case it is a 10ms pulse derived from the clock recovered from an E1/T1 telecoms link.)
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |