[Gllug] Slow over 2meg Satellite

Mark Hemment markhe at veritas.com
Tue Sep 16 17:38:25 UTC 2003


On Mon, 15 Sep 2003 andy at mac1systems.com wrote:

> Hi,
>
> One of my systems is acting as the main server (NATing and SQUIDing) in
> Africa.  Its connected to the UK via a satellite link.
>
> Has anyone experience of using satellite links and how to get a decent
> throughput?  It seems its a common problem having reasonably fast pipes
> with large delay (700ms in this case).
>
> I've googled for days now and tried various things (mainly those discussed
> at http://www.psc.edu/networking/perf_tune.html which most other articles
> seem to reference).
>
> I've increaed the buffers, turned on SACK, Timestamps and windows scaling
> using the following:
>
> 	echo 1 > /proc/sys/net/ipv4/tcp_timestamps
> 	echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
>         echo 1 > /proc/sys/net/ipv4/tcp_sack
>
>        	echo 8388608 > /proc/sys/net/core/wmem_max
>        	echo 8388608 > /proc/sys/net/core/rmem_max
>        	echo "4096 87380 4194304" > /proc/sys/net/ipv4/tcp_rmem
>        	echo "4096 65536 4194304" > /proc/sys/net/ipv4/tcp_wmem
>
> But it doesn't seem to have made any effect.  Running tests from a PC
> connected to the server and FTP directly from the server shows throughput
> of only about 20k tops (and often a lot less) even though only about 30% of
> the pipe is being used.
>
> If I go to the test site mentioned on the psc.edu site
>
> telnet syntest.psc.edu 7960
>
> I get
> =======================================================
> ! Variable        : Val       : Warning (if any)
> !=======================================================
> SACKEnabled       : 3         :
> TimestampsEnabled : 1         :
> CurMSS            : 1448      :
> WinScaleRcvd      : 0         : WARN - 0 WinScale Received
> CurRwinRcvd       : 5840      :
> !
> ! End of SYN options
> !
> Which shows Windows scaling is not enabled.  But
> cat /proc/sys/net/ipv4/tcp_window_scaling
> returns 1.
>
> Is there anything else I need to do to get window scaling working?

  The 'middle' value for tcp_rmem (default size of a TCP receive buffer)
is not large enough for window scaling to be needed - so wscale is set to
0 in the inital SYN.  If you want your test against "syntest" to show
scaling is on, then increase the default slightly;
	echo "4096 90000 174760" > /proc/sys/net/ipv4/tcp_rmem
(better to go higher than 90000).

  Note: Most 'external' servers will not be configured with large socket
	buffers.  They want to be able to handle many simultaneous
	connections fairly, and not have lots of memory "pinned" down
	serving your long fat pipe.

Mark



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list