> 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).


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to