Hello! I have high-speed, high-latency 2-way satellite internet link (currently at 512 kbit/s, RTT=700-800 ms). The problem is that when I establish a tunnel of any kind over that link (gre, ip-ip, even udp-based OpenVPN and VTUN) the TCP speed over that tunnel is absolutely unacceptable. In the examples below 80.x.x.77 (eth0) is my real clean IP address issued by satellite ISP, and 62.x.x.219 (tun0/gre0/etc) is the tunnel address at my end. Let's get some data directly first: > $ wget --bind-address=80.x.x.77 www.xxxx.ru/largefile.zip > ....... > 23:39:00 (60.68 KB/s) - `largefile.zip' saved [1135680/1135680] Now let's try the same via tunnel: > $ wget --bind-address=62.x.x.219 www.xxxx.ru/largefile.zip > ....... > 23:46:28 (4.49 KB/s) - `largefile.zip' saved [1135680/1135680] Note that www.xxxx.ru is located at the other end of the tunnel (62.x.x.217). I've also tried different web-hosts in the internet - with the same results. Also I've analized some tcpdump output, here're the results when transferring data directly: > tcpdump -i eth0 -n > 23:47:12.276897 62.x.x.217.http > 80.x.x.177.44298: . 786941:788401(1460) ack 109 win 32667 > 23:47:12.278185 62.x.x.217.http > 80.x.x.177.44298: . 788401:789861(1460) ack 109 win 32667 > 23:47:12.278195 80.x.x.177.44298 > 62.x.x.217.http: . ack 789861 win 62780 (DF) > 23:47:12.289611 62.x.x.217.http > 80.x.x.177.44298: P 789861:791321(1460) ack 109 win 32667 > 23:47:12.319591 62.x.x.217.http > 80.x.x.177.44298: . 791321:792781(1460) ack 109 win 32667 > 23:47:12.319602 80.x.x.177.44298 > 62.x.x.217.http: . ack 792781 win 62780 (DF) As it can be seen, receiver window size (32667) is large enough to handle this transfer at the maximum possible speed. And here's the output captured on the tunnel interface: > tcpdump -i tun0 -n > 23:53:01.984205 62.x.x.219.44364 > 62.x.x.217.http: . ack 140200 win 63591 <nop,nop,timestamp 20631295 53137471> (DF) > 23:53:01.995589 62.x.x.217.http > 62.x.x.219.44364: . 140200:141553(1353) ack 1 win 5792 <nop,nop,timestamp 53137471 20631222> (DF) > 23:53:01.995598 62.x.x.219.44364 > 62.x.x.217.http: . ack 141553 win 63591 <nop,nop,timestamp 20631296 53137471> (DF) > 23:53:02.033656 62.x.x.217.http > 62.x.x.219.44364: . 141553:142906(1353) ack 1 win 5792 <nop,nop,timestamp 53137475 20631230> (DF) > 23:53:02.033666 62.x.x.219.44364 > 62.x.x.217.http: . ack 142906 win 63591 <nop,nop,timestamp 20631300 53137475> (DF) > 23:53:02.075913 62.x.x.217.http > 62.x.x.219.44364: . 142906:144259(1353) ack 1 win 5792 <nop,nop,timestamp 53137480 20631231> (DF) You can see this differs a lot comparing to the previous capture - much lower window size here (5792) and also SACK seems not willing to work in this case. I've tried everything possible to change and/or tune in /proc/sys/net/ipv4.. Nothing helps. Nothing to read anymore. Maybe tuning of the appropriate tunnel drivers (tun.c, gre.c) would help? Any suggestions? Thanks a lot! -- Best regards, Vlad mailto:vlad@vtx.ru - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
