Messages in this thread | | | From | Min Li <> | Subject | RE: [PATCH net 1/2] ptp: idt82p33: optimize idt82p33_adjtime | Date | Thu, 24 Jun 2021 14:38:46 +0000 |
| |
> -----Original Message----- > From: Richard Cochran <richardcochran@gmail.com> > Sent: June 23, 2021 11:40 PM > To: Min Li <min.li.xe@renesas.com> > 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: > > From: Min Li <min.li.xe@renesas.com> > > > > 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
| |