Thread (12 messages) flat view 12 messages, 2 authors, 2021-07-12

RE: [PATCH net 1/2] ptp: idt82p33: optimize idt82p33_adjtime

From: Min Li <hidden>
Date: 2021-06-24 14:39:00
Also in: lkml

-----Original Message-----
From: Richard Cochran <richardcochran@gmail.com>
Sent: June 23, 2021 11:40 PM
To: Min Li <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 1/2] ptp: idt82p33: optimize idt82p33_adjtime

On Wed, Jun 23, 2021 at 10:46:24AM -0400, min.li.xe@renesas.com wrote:
quoted
From: Min Li <redacted>

The current adjtime implementation is read-modify-write and
immediately triggered, which is not accurate due to slow i2c bus
access. Therefore, we will use internally generated 1 PPS pulse as
trigger, which will improve adjtime accuracy significantly. On the
other hand, the new trigger will not change TOD immediately but delay it
to the next 1 PPS pulse.

Delaying the adjustment by one second (in the worst case) will cause
problems.  User space expects the adjustment to happen before the call to
adjtimex() returns.

In the case of PTP, if new Sync messages arrive before the delayed
adjustment completes, there will be a HUGE offset error, and that will hurt
the PI servo.

So it is better to accept a less accurate jump then to delay the adjustment.

Thanks,
Richard
Hi Richard

Thanks for the review

For linuxptp/ptp4l, we can use step_window to adapt to the slow adjtime.

I have tested this change with ptp4l for by setting step_window to 48 (assuming 16 packets per second)
for both 8265.2/8275.1 and they performed well.

Min
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help