Re: [net-next 03/15] net/mlx5: Add adjphase function to support hardware-only offset control
From: Richard Cochran <richardcochran@gmail.com>
Date: 2023-01-23 02:15:32
Wow, lots of confusion in this thread! On Fri, Jan 20, 2023 at 03:58:25PM -0800, Jacob Keller wrote:
Sure. I guess what I don't understand is why or when one would want to use adjphase instead of just performing frequency adjustment via the .adjfine operation...
The difference is in where the frequency adjust is calculated. There are two possibilities: 1. It may be done in user space. This is NTP timex's ADJ_FREQUENCY. PHC implements .adjfine 2. It may be left to kernel space. This is NTP timex's ADJ_OFFSET. PHC implements .adjphase In case of #2, the hardware implements some kind of clock servo. The inputs to the servo are the reported phase offsets. The output of the servo is a frequency adjustment.
Especially since "gradual adjustment over time" means it will still be slow to converge (just like adjusting frequency is today).
It depends on the servo parameters.
We should definitely improve the doc to explain the diff between them and make sure that its more clear to driver implementations.
Sure.
It also makes it harder to justify mapping small .adjtime to .adjphase,
adjtime is totally different. Don't mix those two up: - adjtime sets the time (phase), plain and simple. - adjphase feeds the phase offsets into a servo algorithm in hardware. FWIW, the PHC subsystem handles the semantics of timex ADJ_FREQUENCY and ADJ_OFFSET in exactly the same way as the NTP subsystem. Thanks, Richard