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.
> 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.000006514
delay=0.000006405
delay=0.000006392
delay=0.000006351
delay=0.000006445
delay=0.000006390
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
