This is a discussion on other tcp mss issues/questions - Networking ; I'm experimenting with a network here, with the following characteristics: machine A (WinXP home) | | 100Mbit Ethernet | gateway R (linux 18.104.22.168-20a) | | 15Mbit/second | pseudo-ethernet | serial link | gateway H (linux 22.214.171.124-20a) | | 100Mbit ethernet ...
I'm experimenting with a network here, with the following
machine A (WinXP home)
| 100Mbit Ethernet
gateway R (linux 126.96.36.199-20a)
| serial link
gateway H (linux 188.8.131.52-20a)
| 100Mbit ethernet
machine B (WinXP MCE)
Default route runs from A to B.
For some reason, I'm only getting about 10Mbit/second from the serial
link, and am trying to figure out why.
I'm measuring throughput by transferring a 50Mbyte file from A to B
via ftp. I noticed that the packets are actually, apparently, being
generated as 2068-byte packets for some reason, and are getting
fragmented into two packets of 1500 bytes and 652 bytes. Thus, I show:
24452 packets of 1524 bytes (tcp packets)
24468 packets of 652 bytes (tcp packets)
24450 packets of 70 bytes (tcp packets)
Well, I certainly don't want the stream to be fragmenting packets, so
I've tried changing the mss or mtu of the link, but nothing really
works. For example, if I try:
ifconfig eth0 mtu 1460
on *either* side of the link, it simply stops passing packets at
all!! I can connect in the ftp session, but dir hangs (eventually
times out and disconnects). Other attempts such as setting mss in the
routes, or using iptables to specify mss as documented elsewhere in
this group, have no effect on the fragmenting.
BTW, I have NO firewalls running on any machines.
So I have several questions:
1. Why didn't my ifconfig technique work?? I thought the Windows
machine(s) would discover the smaller packet size and revised their
mss as required, but it doesn't seem to happen; maybe I should reboot
2. Why is the Windows machine generating >2KB packets in the first
place?? I ran TCP Optimizer on both Windows machines, and explicitly
set the MTU to 1500 bytes on all interfaces, but this wasn't
3. Is there something obvious that I'm just not understanding about
I also looked at the Berkeley Labs TCP Tuning Guide, and set the
optimizations that it recommended on the linux machines:
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
But none of these affected the fragmentation, nor the throughput
limitations, in any way.