Thread (59 messages) 59 messages, 8 authors, 2023-01-25

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help