> On Wed, 6 Oct 1999, Steve Dodd wrote:
>
> |I'm stuck. FTP downloads over my PPP link are fine, they pretty much saturate
> |the connection when the remote host can send that fast. Uploads are a different
> |matter: regardless of the remote host I'm uploading to, the xfer rate withers
> |away to sod-all and a huge gob of data remains resolutely stuck in the
>
> Here is a third-hand suggestion that popped up in a reply to a similar
> problem on comp.os.linux.networking:
>
> # RFC 1323 "TCP Extensions for High Performance"
> echo -n 0 > /proc/sys/net/ipv4/tcp_window_scaling
> echo -n 0 > /proc/sys/net/ipv4/tcp_timestamps
> # RFC 2018
> echo -n 0 > /proc/sys/net/ipv4/tcp_sack
I snipped this off and executed it on both my machines.
Here are the results:
This sends with a mtu of 1500
asyncmap 00000000
pppd was started with no Van Jacobsen all cases with no quoted characters.
ftp> bin
200 Type set to I.
ftp> put platinum.tar.gz
local: platinum.tar.gz remote: platinum.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for platinum.tar.gz.
226 Transfer complete.
109842 bytes sent in 36.3 secs (3 Kbytes/sec)
This sends with a mtu of 576
asyncmap 00000000
ftp> bin
200 Type set to I.
ftp> put platinum.tar.gz
local: platinum.tar.gz remote: platinum.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for platinum.tar.gz.
226 Transfer complete.
109842 bytes sent in 31 secs (3.5 Kbytes/sec)
This sends with a mtu of 256
asyncmap 00000000
ftp> bin
200 Type set to I.
ftp> put platinum.tar.gz
local: platinum.tar.gz remote: platinum.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for platinum.tar.gz.
226 Transfer complete.
109842 bytes sent in 31.2 secs (3.4 Kbytes/sec)
This receives with a mtu of 1500
asyncmap 00000000
ftp> get platinum.tar.gz
local: platinum.tar.gz remote: platinum.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for platinum.tar.gz (109842 bytes).
226 Transfer complete.
109842 bytes received in 42.5 secs (2.5 Kbytes/sec)
This receives with a mtu of 576
asyncmap 00000000
ftp> get platinum.tar.gz
local: platinum.tar.gz remote: platinum.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for platinum.tar.gz (109842 bytes).
226 Transfer complete.
109842 bytes received in 42.9 secs (2.5 Kbytes/sec)
This receives with a mtu of 256
asyncmap 00000000
ftp> get platinum.tar.gz
local: platinum.tar.gz remote: platinum.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for platinum.tar.gz (109842 bytes).
226 Transfer complete.
109842 bytes received in 41.9 secs (2.6 Kbytes/sec)
My tentative conclusion is that the mtu does nothing and the transfer
rate is rotten.
tcpdump shows that about every other packet is lost. Many more packets
are lost if I get any other traffic on the link. For instance, if
I ping a host (1-second pings), the data-flow disappears. Most all
packets time out and are re-sent. The ping response is in 700 to
900 ms and many are missing (18% packet loss). If there is no data
transfer, I can ping with no packet loss.
The ping transfer time on a quiet link is 190.0 ms with 8 data-bytes.
This does not compute. Ping flood with 8 data-bytes shows 54% data
loss. Ping flood with the standard 56 data bytes shows 100% data
loss.
Cheers,
Dick Johnson
**** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/