On 9/26/12 10:55 PM, Andre Oppermann wrote: > On 23.09.2012 17:35, Andrey Zonov wrote: >> On 9/20/12 11:35 AM, Eggert, Lars wrote: >>> Hi, >>> >>> On Sep 20, 2012, at 9:25, Andrey Zonov <[email protected]> wrote: >>>> Some of them may be read google's article about tuning TCP parameters >>>> [1]. I convert most of TCP timers to sysctls [2] and we are using this >>>> patch for few months. We tuned net.inet.tcp.rtobase and >>>> net.inet.tcp.syncache.rexmttime and it gives good results >>>> (especially in >>>> conjunction with cc_htcp(4)). >>> >>> can you share some measurements that quantify the results? >>> >> >> When we set net.inet.tcp.syncache.rexmttime=200 and >> net.inet.tcp.syncache.rexmtlimit=7 for our external web service, the >> number of duplicated SYN was reduced in four times. > > This isn't surprising. You're simply trading retransmits by the client > with retransmits by the server. Whether this is within the overall packet > conservation principle is not clear. On the timeline it may be an > advantage. >
This is great improvement for us. 2% of our users don't wait for 3 seconds any more. > I'm not comfortable with the rather low retransmit time you've chosen > here. Considering higher RTT's (e.g. Hawaii or JP/CN) and the bufferbloat > problem this may be too low. When it is to be tuned, then something in the > range of 500-1000ms may be more realistic to avoid spurious retransmits. > For example Linux some time ago set RTO to 1 sec. OSX for a long time has RTO 1 sec. > When a SYN or SYN/ACK retransmit happens, the initial CWND should be > reduced > per the applicable RFC's as this indicates packet loss on the downstream. > -- Andrey Zonov
signature.asc
Description: OpenPGP digital signature
