Re: [Linuxptp-devel] measuring accuracy/precision of software timestamping when using ptp4l
> -Original Message- > From: Miroslav Lichvar [mailto:mlich...@redhat.com] > Sent: Friday, October 05, 2018 1:37 AM > To: Keller, Jacob E > Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran > (richardcoch...@gmail.com) > Subject: Re: measuring accuracy/precision of software timestamping when using > ptp4l > > On Thu, Oct 04, 2018 at 03:38:41PM +, Keller, Jacob E wrote: > > > On Wed, Oct 03, 2018 at 09:39:14PM +, 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? > > Yes, I think that's how it's supposed to work, but I'm not sure if a > driver couldn't put there a more accurate timestamp earlier. > > Ideally, the RX timestamp would be taken right after the interrupt (if > there was one), like with PPS for instance. I'm sure it's technically possible, but I don't know if there is an available kernel interface for doing so. Thanks, Jake > > -- > Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] measuring accuracy/precision of software timestamping when using ptp4l
On Thu, Oct 04, 2018 at 03:38:41PM +, Keller, Jacob E wrote: > > On Wed, Oct 03, 2018 at 09:39:14PM +, 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? Yes, I think that's how it's supposed to work, but I'm not sure if a driver couldn't put there a more accurate timestamp earlier. Ideally, the RX timestamp would be taken right after the interrupt (if there was one), like with PPS for instance. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] measuring accuracy/precision of software timestamping when using ptp4l
> -Original Message- > From: Miroslav Lichvar [mailto:mlich...@redhat.com] > Sent: Thursday, October 04, 2018 3:30 AM > To: Keller, Jacob E > Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran > (richardcoch...@gmail.com) > Subject: Re: measuring accuracy/precision of software timestamping when using > ptp4l > > On Wed, Oct 03, 2018 at 09:39:14PM +, 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.06514 > delay=0.06405 > delay=0.06392 > delay=0.06351 > delay=0.06445 > delay=0.06390 > 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
Re: [Linuxptp-devel] measuring accuracy/precision of software timestamping when using ptp4l
On Wed, Oct 03, 2018 at 09:39:14PM +, 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. > 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. 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.06514 delay=0.06405 delay=0.06392 delay=0.06351 delay=0.06445 delay=0.06390 A patch is necessary to print the error of the SW RX timestamp. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
