On 14 December 2011 11:27, Rick Jones <[email protected]> wrote: > While looking at "something else" with tcpdump/tcptrace, tcptrace emitted > lots of notices about hardware duplicated packets being detected (same TCP > sequence number and IP datagram ID). Sure enough, if I go into the tcpdump > trace (taken on the sender) I can find instances of what it was talking > about, separated in time by rather less than I would expect to be the RTO, > and often as not with few if any intervening arriving ACKs to trigger > anything like fast retransmit. And besides, those would have a different IP > datagram ID no? > > I did manage to reproduce the issue with plain netperf tcp_stream tests. I > had one sending system with 30 concurrent netperf tcp_stream tests to 30 > other receiving systems. There are "hardware duplicates" in the sending > trace, but no duplicate segments (that I can find thus far) in the two > receiver side traces I took. Of course that doesn't mean "conclusively" > there were two actual sends but it suggests there werent. > > While I work through the "obtain permission" path to post the packet traces > (don't ask...) I thought I would ask if anyone else has seen something > similar. > > In this case, all the systems are running a 2.6.38-8 Ubuntu kernel (the same > sorts of issues which delay my just putting the traces up on netperf.org > preclude a later kernel, and I've no other test systems :( ), with Intel > 82576 interfaces being driven by: > > $ sudo ethtool -i eth0 > driver: igb > version: 2.1.0-k2 > firmware-version: 1.8-2 > bus-info: 0000:05:00.0 > > All the systems were connected to the same switch. >
Rick, This may be of help. http://www.tcptrace.org/faq_ans.html#FAQ%2021 Regards, Vijay Subramanian - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
