RE: VSAT sysctl parameters

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



thank you !

I will post all my results...
regards.

-> 
-> 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/
-> 
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux