From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keller, Jacob E" Subject: RE: Improving accuracy of PHC readings Date: Fri, 19 Oct 2018 16:52:13 +0000 Message-ID: <02874ECE860811409154E81DA85FBB5884CDD9F4@ORSMSX115.amr.corp.intel.com> References: <20181019095137.GG4407@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: Richard Cochran To: Miroslav Lichvar , "netdev@vger.kernel.org" Return-path: Received: from mga01.intel.com ([192.55.52.88]:45343 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727549AbeJTA7J (ORCPT ); Fri, 19 Oct 2018 20:59:09 -0400 In-Reply-To: <20181019095137.GG4407@localhost> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: > -----Original Message----- > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On > Behalf Of Miroslav Lichvar > Sent: Friday, October 19, 2018 2:52 AM > To: netdev@vger.kernel.org > Cc: Richard Cochran ; Keller, Jacob E > > Subject: Improving accuracy of PHC readings > > I think there might be a way how we could significantly improve > accuracy of synchronization between the system clock and a PTP > hardware clock, at least with some network drivers. > > Currently, the PTP_SYS_OFFSET ioctl reads the system clock, reads the > PHC using the gettime64 function of the driver, and reads the system > clock again. The ioctl can repeat this to provide multiple readings to > the user space. > > phc2sys (or another program synchronizing the system clock to the PHC) > assumes the PHC timestamps were captured in the middle between the two > closest system clock timestamps. > > The trouble is that gettime64 typically reads multiple (2-3) registers > and the timestamp is latched on the first one, so the assumption about > middle point is wrong. There is an asymmetry, even if the delays on > the PCIe bus are perfectly symmetric. > Right! I feel like this is obvious now that you said it, so I'm surprised no one thought of it before... > A solution to this would be a new driver function that wraps the > latching register read with readings of the system clock and return > three timestamps instead of one. For example: > > ktime_get_real_ts64(&sys_ts1); > IXGBE_READ_REG(hw, IXGBE_SYSTIMR); > ktime_get_real_ts64(&sys_ts2); > phc_ts.tv_nsec = IXGBE_READ_REG(hw, IXGBE_SYSTIML); > phc_ts.tv_sec = IXGBE_READ_REG(hw, IXGBE_SYSTIMH); > > The extra timestamp doesn't fit the API of the PTP_SYS_OFFSET ioctl, > so it would need to shift the timestamp it returns by the missing > intervals (assuming the frequency offset between the PHC and system > clock is small), or a new ioctl could be introduced that would return > all timestamps in an array looking like this: > > [sys, phc, sys, sys, phc, sys, ...] > I think the new ioctl is probably the better solution. > This should significantly improve the accuracy of the synchronization, > reduce the uncertainty in the readings to less than a half or third, > and also reduce the jitter as there are fewer register reads sensitive > to the PCIe delay. > > What do you think? > Nice! I think this is good. I'd love to see some data to back it up, but it makes sense to me. Thanks, Jake > -- > Miroslav Lichvar