Re: Hardware Timestamping Problem

[Guenter Ebermann <guenter.ebermann () googlemail com>]

> Am 08.06.2016 um 23:10 schrieb Michael Richardson <mcr () sandelman ca>:
>
> Christian Rupp <christian.rupp.stuttgart () freenet de> wrote:
> > The Timestamp when tcpdump grabs the package off of the receiver is 36
> > seconds( +/- innaccuracy, here roughly  +/- 5-10 µs) after the timestamp when
> > tcpdump grabs the package of the sender. resulting in an alleged One
> > Way
> > Delay of 36 seconds which wouldn't make any sense in that scenario, given
> > that the software timestamping option and the -j adapter option both result
> > in a ~ 100-200µs one way delay
>
> The timestamp on the sender is long before the hardware.
> You are saying that the stamp is correct when you do not use the -j option?
>
> if that's the case, then it seems like it's the hardware which is mis-stamping.

Hardware timestamping of sending/receiving buffer descriptors is done by NIC.
Configured by the NIC-driver (timer resolution of NIC timestamping clock).
Setup by the user space application via kernel interface(s) [1]
Therefore I would try to run a recent Linux kernel and a recent tcpdump. You 
may even change to another NIC for testing.

[1] https://www.kernel.org/doc/Documentation/networking/timestamping.txt



_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers