> On Sep 19, 2016, at 3:08 PM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote: > > This is because RTT of this link for jumbo frames higher 1500 bytes > frame for store-and-forward switch chain.
For TCP, RTT isn't really a factor (in this scenario), as the windowing and congestion avoidance algorithms will adapt to the actual bandwidth-delay product of the link, and the delays in each direction will be symmetrical. Now the ack for a single 9000 octet packet will take longer than that for a 1500 octet one, but that's because you're sending six times as many octets before the ACK can be generated. The time to send six 1500 octet packets and receive the ACK from sixth packet is going to be comparable to that of receiving the ack from a single 9000 octet packet. It's simple arithmetic to calculate the extra protocol header overhead for 6x1500 vs 1x9000. If there *is* a significant difference (beyond the extra protocol header overhead), it's time to take a very close look at the NICs you are using in the end hosts. A statistically significant difference would hint at poor interrupt handling performance on the part of one or more of the NICs and their associated device drivers. The intermediate switch overhead will be a constant (unless the switch backplane becomes saturated from unrelated traffic). --lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
