Re: [tcpdump-workers] Hardware Timestamping Problem
Yes, one tcpdump entity per server, after Both are started I start a
Package Generator which sends a 900kbs Trace.
There shouldn't be a big buffering effect, if I'm not using the hardware
timestamp options the one way delay is at a few 100 µs, or am I
misunderstanding something?
The 36 seconds are only showing up, when I'm using the -j
adapter_unsynced option.
The goal is to measure the one way delay, so I simply take the timestamp
of the Receiver and subtract the timestamp of the sender.
I'm using ptp4l for the synchronisation.(I have run ptp oder the same
link as the measurement, and on a different link, synchronising the
clocks with phc2sys. Both implementations had the 36s error)
Am 08.06.2016 um 16:24 schrieb Michael Richardson:
{please keep it on the list for archival purposes}
Christian wrote:
> between sender and receiver
> so from the point when tcpdump grabs the time off of the Sender and to
the
> point where tcpdump grabs the time off of the receiver.
So you are running a tcpdump on sender, using the timestamping service from
the hardware, and the same on receiver, and then you send traffic?
How much traffic? Is it being buffered?
How do you correlate traffic?
How are the *hardware* clocks being synchronzied?
AFAIK, no NICs timestamp traffic on outgoing, tcpdump captures before the
hardware queue. A big hardware send buffer would result in significant skew.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
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 Am 08.06.2016 um 22:13 schrieb Guy Harris: On Jun 8, 2016, at 5:53 AM, Christian wrote: Now, my results in itself make sense and would give me the desired results, but they have a big offset to them. 36 seconds to be exact. So you're saying there's a 36-second offset between which two times? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Problems with ns Timestamps
Yes the tenth digit, sorry English isn't my first language. SO yes 1.05 is printed as 1.5 Tcpdump is printing a good timestamp wrong, as far as i can tell. The Timestamp in itself, if the 0 would be there, would be completely okay and would make sense. Am 28.07.2016 um 20:50 schrieb Guy Harris: On Jul 28, 2016, at 7:12 AM, Christian wrote: I have encountered a problem. I am capturing Packages with hardware timestamps and nanosecond precision...but the timestamps are bugged. sadly I'm not at the place where I captured the data, so the used used command might be slightly different, as I have to work from my memory: tcpdump -i eth4 port 0 -v -tt -j adapter_unsynced --time-stamp-precision=nano > dumpfile The problem is, that if the time is at below 100ms, the 0.1 field is not 0 as it should be, but doesn't exist. So by "the 0.1 field" you mean "the tenths digit", so that, for example, a time stamp of 1.05 seconds would appear as 1.5? And are you saying that libpcap is providing bad time stamps, with an incorrect nanoseconds field, or are you saying that tcpdump is incorrectly printing a good time stamp? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
