I contacted you before 5 weeks asking for help about overlapping outgoing packets in time in wireshark program. And you told me that the problem is in timestamping of outgoing packets. So the packets were timestamped on host and because of that there was delay of actual sending of packets and they were overlapped. You told me to make outgoing packets be timestamped on the card so they would be more precisely measured. Then I bought Intel i210-t1 network card (kernel 3.3.4-5.fc17.i686.PAE Fedora 17) and compiled igb driver with PTP (Precision Time Protocol) option and with tcpdump command and -j adapter option captured traffic on that network card. I hoped that now outgoing won't be overlapped in time but they still are overlapped. So I am surprised how is it possible that when they are timestamped on the card there would be overlapping of outgoing packets. When igb driver is not compiled with PTP option tcpdump gives warning that timestamping on the card is not supported but when I compiled with that option everything has gone well, not any warning was printed when I started tcpdump with -j adapter option. Do you know what can be the problem so the outgoing packets are still overlapped? Thank you in advance, Milutin Aksic. asked 22 Jul '13, 10:48  micacim edited 22 Jul '13, 11:01  SYN-bit ♦♦ |
One Answer:
Maybe this is due to (TCP) offloading in the driver. Please try to disable that with ethtool (see man page - Option -k / -K). Regards answered 23 Jul '13, 10:14  Kurt Knochner ♦ Thank you for the last answer this tcp offloading helped me to reduce the overlapping but there are still some overlapping for certain packets if you can see. This is the link to new capture file: https://www.dropbox.com/s/kl0i6s4s77w2wfw/ts3_src.pcap For example for packets no. 564, 747, 920, 954, 999, there are overlappings. Do you know what is the reason for this? Regards, Milutin. (24 Jul '13, 01:11) micacim I'd not expect to see correct timestamps as long as you have NOT successfully turned off TCP offloading. As you can see in your provided trace those +1518bytes frames are all "virtual" and contain more than one physical packet - so their timestamps can't almost be correct (24 Jul '13, 02:16) Landi
wait a moment. Did you enable or disable TCP offloading? I asked you to disable it, as well as any other form of offloading ;-) See the man page of ethtool. Option -k will tell you if there is any offloading enabled on your system. Could you please post the output of
If eth0 is your interface... (24 Jul '13, 03:50) Kurt Knochner ♦ This is the output of ethtool -k eth0 after I disabled all offloads: and the capture file is at: https://www.dropbox.com/s/qdgr65carh0r5sz/ts_sto.pcap Regards, Milutin. (25 Jul '13, 08:37) micacim please disable checksumming and scatter-gather as well and then re-try. (25 Jul '13, 10:56) Kurt Knochner ♦ After I disable checksumming and scatter-gather output of ethtool -k is: and the link to capture file is: https://www.dropbox.com/s/qdgr65carh0r5sz/ts_sto.pcap There are still overlappings. (26 Jul '13, 01:35) micacim What are the frames, you think there is overlapping? (26 Jul '13, 01:39) Kurt Knochner ♦ I sent you capture file and there you can see that there are still overlappings. (26 Jul '13, 01:47) micacim please tell me the frames. (26 Jul '13, 01:48) Kurt Knochner ♦ What do you mean tell me the frames? (26 Jul '13, 01:51) micacim I sent you capture file. You can see the frames there. (26 Jul '13, 01:55) micacim @micacim Your multiple "answers" have been converted to comments as that's how this site works. Please read the FAQ for more information. (26 Jul '13, 01:58) grahamb ♦
tell me the frame number, where you think there is overlapping. Just to ensure we are talking about the same thing! (26 Jul '13, 02:59) Kurt Knochner ♦ BTW: As I don't know how time stamping is implemented internally on the card, I suspect that the packet is not time stamped when it is really transmitted, but when the NIC hardware receives the packet from the system, before it is placed in an internal send buffer. That would explain why you see time stamp deltas that are smaller than the transmit time of a frame. The only way to figure this out is probably by asking Intel. (26 Jul '13, 03:08) Kurt Knochner ♦ Can you send me the link of the web page where I should ask Intel about my problem. I have put it on Intel Community forum but nobody answered. Thank you in advance, Milutin. (26 Jul '13, 09:20) micacim
I don't know the Intel Support Organization. As you have bought the NIC, I suggest to read the accompanying documents. I'm sure there is a hint how to contact Intel Support. Otherwise, I suggest to search google for: Intel support. (27 Jul '13, 00:09) Kurt Knochner ♦ Hello, I need to tell you something. I have captured the traffic with tcpdump -j adapter and tcpdump -j host, with timestamping enabled and disabled, and in both cases delays of packets are the same so I think that timestamping was not done at all although there was no any warrning saying that this type of timestamping was not supported. How is it possible that there was no any timestamping on the card? (31 Jul '13, 06:15) micacim
Maybe a bug in the linux/libpcap/tcpdump code or a bug in the NIC firmware? (08 Aug '13, 08:04) Kurt Knochner ♦ showing 5 of 18 show 13 more comments |
What is the output of the following command?
What was the parameter you chose for
tcpdump -j?can you please post a sample capture file somewhere?
Hello, The output of the command tcpdump -ni eth0 -J is:
Time stamp types for eth0 (use option -j to set): host (Host) adapter (Adapter) adapter_unsynced (Adapter, not synced with system time)The parameter for tcpdump -j command was 'adapter' and link to the capture file is: https://www.dropbox.com/s/i2qyr99v690u47h/ts_src.pcap For example in this file for packet 12. with sending time 0.299593 and length 1514 bytes on the link of 100Mb/s duration is about 115 microseconds but the next packet 13. is sent only 9 microseconds after the beginning of 12.packet. So they are overlapped. How is it possible?