Re: [TEST] txtimestamp.sh pains after netdev foundation migration

[Jakub Kicinski <kuba@kernel.org>]

Thanks for investigating!

On Wed, 07 Jan 2026 19:19:53 -0500 Willem de Bruijn wrote:
> 17 out of 20 happen in the first SND-USR calculation.
> One representative example:
> 
>     # 7.11 [+0.00] test SND
>     # 7.11 [+0.00]     USR: 1767443466 s 155019 us (seq=0, len=0)
>     # 7.19 [+0.08] ERROR: 18600 us expected between 10000 and 18000
>     # 7.19 [+0.00]     SND: 1767443466 s 173619 us (seq=0, len=10)  (USR +18599 us)
>     # 7.20 [+0.00]     USR: 1767443466 s 243683 us (seq=0, len=0)
>     # 7.27 [+0.07]     SND: 1767443466 s 253690 us (seq=1, len=10)  (USR +10006 us)
>     # 7.27 [+0.00]     USR: 1767443466 s 323746 us (seq=0, len=0)
>     # 7.35 [+0.08]     SND: 1767443466 s 333752 us (seq=2, len=10)  (USR +10006 us)
>     # 7.35 [+0.00]     USR: 1767443466 s 403811 us (seq=0, len=0)
>     # 7.43 [+0.08]     SND: 1767443466 s 413817 us (seq=3, len=10)  (USR +10006 us)
>     # 7.43 [+0.00]     USR-SND: count=4, avg=12154 us, min=10006 us, max=18599 us

Hm, that's the first kernel timestamp vs the timestamp in user space?
I wonder if we could catch this by re-taking the user stamp after
sendmsg() returns, if >1msec elapsed something is probably wrong 
(we got scheduled out before having a chance to complete the send?)

> These are just outside the bounds of 18000. So increasing the
> tolerance in txtimestamp.sh will probably mitigate them. All 17
> would have passed with the following change.
> 
> -        local -r args="$@ -v 10000 -V 60000 -t 8000 -S 80000"
> +        local -r args="$@ -v 10000 -V 60000 -t 8000 -S 100000"
> 
> Admittedly a hacky workaround that will only reduce the rate.
> 
> It's interesting that
> 
> - every time it is the first of the four measurements that fails.
> - it never seems to occur for TCP sockets.

FWIW:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/net/results/449080/13-txtimestamp-sh/stdout
but that could be related to some bad patch..