> -----Original Message----- > From: Miroslav Lichvar [mailto:mlich...@redhat.com] > Sent: Thursday, October 04, 2018 3:30 AM > To: Keller, Jacob E <jacob.e.kel...@intel.com> > Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran > (richardcoch...@gmail.com) <richardcoch...@gmail.com> > Subject: Re: measuring accuracy/precision of software timestamping when using > ptp4l > > On Wed, Oct 03, 2018 at 09:39:14PM +0000, Keller, Jacob E wrote: > > I'm investigating a potential software driver bug in which a driver calls > skb_tx_timestamp earlier than necessary, and I want to gather some > informational > data to indicate whether or not moving the function to a later point in the > driver tx/rx > path would actually improve the accuracy/precision. > > You mean the TX path only? An RX timestamp should be captured as soon > as possible. >
This is Tx path, because that's the bit controlled by the drivers. AFAIK the Rx timestamping is done by the stack when the driver pushes the SKB up, right? > > I recall seeing some fancy graphs of this data posted to the list, and was > > curious if > anyone had an easy way to generate a graph to indicate whether the change was > an > improvement or not. Specifically, the software timestamping varies enough > that it is > difficult to determine just at a glance whether behavior has been improved or > not. > > You can compare the delay printed by ptp4l. A smaller delay means that > the sum of errors in the TX and RX timestamps is smaller. This assumes > that nothing else has changed and the RX/TX timestamp is still > captured after/before the reception/transmission respectively. Right. This makes sense. > > If the NIC supports HW timestamping and the driver can capture both SW > and HW RX/TX timestamps at the same time (hopefully all drivers in the > mainline now support it), you can compare them directly to get an > estimate of the error in the SW timestamps. chronyd prints this value > for the TX timestamp in its debug output. It can be extracted like this: > > # chronyd -d -d 'server $SERVER minpoll 0 maxpoll 0' 'hwtimestamp eno1' |& \ > grep --line-buffered -A 1 'Received.*queue.*tss=2' | grep -o delay=.* > delay=0.000006514 > delay=0.000006405 > delay=0.000006392 > delay=0.000006351 > delay=0.000006445 > delay=0.000006390 > Neat, I'll check this out. > A patch is necessary to print the error of the SW RX timestamp. I wasn't planning on investigating the RX side, because this was handled by the netdev stack, and not by the driver, if I recall correctly. Thanks, Jake > > -- > Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
