Hi, > -----Original Message----- > From: Oliver Westermann [mailto:owesterm...@gmail.com] > Sent: Friday, February 16, 2018 1:20 AM > To: Richard Cochran <richardcoch...@gmail.com> > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] Handling missing hardware timestamps on > embedded systems > > I may have run into a design constraint which I understood now, hopefully. > > The issue were to strict timeouts that sometimes ran into an issue. > The current process is like this: > > - ptp4l sends a DELAY_REQ package into the network stack and sends a SKB to > retrieve the timestamp > - when the PHY handles it, it saves the timestamp and generates an interrupt > - the interrupt handler of my PHY reads seq_id and timestamp and places an > event with both into a queue > - the PHY worker fetches the SKBs and searches for matching events in the > queue >
So you're likely adding increased delays and potential pitfalls for a couple reasons here: When ptp4l sends a delay request, it indicates an SKB which sets the SKBTX_HW_TSTAMP bit. Your driver responds to this by setting the SKB_TX_IN_PROGRESS bit which indicates that you will be doing a Tx timestamp. You should only set this bit if you are capable of generating a timestamp. If your hardware can only timestamp one packet at a time, then you should be sure to never set this again until the outstanding request is finished, and it is expected that most hardware only supports one outstanding request at once. That's one pitfall you should be aware of. Next, you have an interrupt which the PHY signals that a timestamp is ready, followed by a separate worker thread to handle this? The problem with an extra worker thread here, is that it will potentially be hit by unknown delays due to scheduling. If possible you may be able to handle the work directly in the interrupt thread. Especially easy if you only support a single outstanding timestamp request, since there wouldn't need to be a queue at all. > I added some tracing into ptp4l and my phy driver and measured the timings > over > some minutes of PTP (with additional load on the network interface, additional > load on cpus, all timeouts set to 100ms, 2170 measurements): > > send to interrupt, mean/standard deviation/max in ms: 2,97 / 1,48 / 12,85 > > interrupt to match: 0,55 / 0,16 / 6,86 > send to match: 3,52 / 1,62 / 13,21 > > From that perspective my tx_timestamp_timeout of 10ms was to short. I would > raise it to 18ms (~50% extra margin). > So if I understand this correctly, the mean time to match is 3.5 seconds, but there's occasional stalls? Even the interrupt itself takes up to 12 ms sometimes? It's quite possible that's just time until you service the interrupt, which could be impacted by a number of things. A number of other drivers forgo using interrupts, and instead poll using the "do_work" ptp kernel thread, which is likely more resillient against delays compared to something such as a workqueue item. > Is there a reason not to do this? You can change the configuration to fit what you need, but I suspect this can be fixed by improving the driver. Thanks, Jake > > Thanks, Olli ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
