> Am 08.06.2016 um 23:10 schrieb Michael Richardson <m...@sandelman.ca>: > > Christian Rupp <christian.rupp.stuttg...@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
