hi andres, i re-read your question and now that i have a bit more time, i'll try to respond to it more carefully: On Fri, 2004-02-13 at 21:37, ThE LinuX_KiD wrote: > Hi, > > I'm trying to setting a very low bandwidth > VSAT connection (90 kbits download / 20kbits upload) > > I'm looking for best kernel SYSCTL parameters for this > > Have someone a sysctl configuration for this ? your question implies that the vsat system that you're currently using is un-optimized by the provider -- i'll try to explain. here in europe, the two principal providers Eutelsat and Satlynx both offer true two-way satellite service that are asymmetrical in bandwidth. the eutelsat d-start product as well as the satlynx 360e are both optimized by the provider, that is to say, that both re-negotiate the layer 4 tcp connection parameters for each tcp session. if you take the time to try to reset the tcp parameters, it is really unnecessary as they are thrown out and replaced by the providers variables (performed by the indoor unit). the exceptions are the astra bbi platform and other "pure" vsat platforms that do not perform layer 4 renegotiation or ack spoofing and the like. at this point, tweaking the sysctl parameters helps enormously, however, it is noteworthy that a client passing its traffic via your linux router, will not inherit the router's parameters: each client will setup its own tcp parameters during the handshake. so, here's a brief summary: squid and/or another http proxy: a http proxy server is recommended in all cases. setup a large cache, good memory and cache object size. avoid using the bandwidth if you do not have to. satlynx 360e: no need to much here with your router, excepting that you should really try to make use of the http proxy port (9877) provided by the indoor unit. you can setup a transparent squid proxy (or regular) and put a line in the squid.conf like: cache_peer $GILAT_INDOOR_IP parent 9877 0 no-query when squid doesn't find the cache object, it will send the http request through their proxy port and you will enjoy the benefits of their caching and acceleration. eutelsat d-star: like the gilat, eutelsat has optimized their backbone with ack spoofing and tcp layer renegotiation. no need to worry about clients behind this idu either. astra bbi and other "pure" vsat connections: here you will want to do your maximum effort to tweak sysctl and use a proxy so that the linux router will use its tcp paramters at layer 4. here's a few suggestions for sysctl.conf, your mileage may vary: net.core.wmem_max = 8388608 net.core.rmem_max = 8388608 net.ipv4.tcp_wmem = 4096 200000 250000 net.ipv4.tcp_rmem = 4096 200000 250000 net.ipv4.tcp_dsack = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 #net.ipv4.tcp_wmem = 4096 87380 4194304 #net.ipv4.tcp_wmem = 4096 250000 300000 #net.ipv4.tcp_rmem = 4096 87380 4194304 #net.ipv4.tcp_rmem = 4096 150000 200000 the # statements were taken from several howtos and you should give them a try to see if your getting improvements. remember again that using squid will cause these parameters to be used as opposed to a client behind that does its own layer 4 negotiation. iptables patches may be of help as well to get a clients tcp negotiation to support better congestion window size. older ip stacks (i.e. win 95 and nt 40) can be problematic as these paramters cannot be changed (as far as i know). patience, testing, and let us know! cheers charles _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
