Date: Sun, 21 Jul 2002 17:50:27 +0200 From: Andre Oppermann <oppermann@pipeline.ch> To: Mike Silbersack <silby@silby.com> Cc: Garrett Wollman <wollman@lcs.mit.edu>, Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_timer.h Message-ID: <3D3AD843.C84F3742@pipeline.ch> References: <20020719134639.S95326-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack wrote: > > On Thu, 18 Jul 2002, Garrett Wollman wrote: > > > - He questioned whether the traditional VJ `srtt + 4*rttvar' > > computation captures enough of the variance in the real Internet to > > avoid unnecessary slow retransmits. > > > > - He also notes that there have not been screams of protest since > > Linux adopted the 200-ms minimum, which suggests that it's not a > > completely hare-brained value. > > > > -GAWollman > > Now that I've had a bit more time to think it over, I believe that Matt's > 200ms slop + no floor on rtomin provides us with a very good system. In > effect, Matt has seperated the delay necessary to avoid retrans because of > delayed acks (200ms or less on modern systems) from rtt (quite variable.) > This is an approach that seems quite obvious in hindsight, and should > allow the tcp stack to adapt to varying link types quite dynamically. > > The main improvement upon this I could see is dynamically detecting the > delayed ack period of the receiver, as suggesed by DG. Unfortunately, I > suspect that such detection would be nearly impossible to get correct. In September/October I get two Students doing their Master here and the task I've assigned to them is to track the real-world observed behaviour of TCP at five major sites here in Switzerland. These sites are chosen to give a statistically correct representation of the Swiss Internet demographics. We'll get 128 Byte tcpdumps of 7 days. These dumps will be analysed for TCP. The data will be very interesting because in Switzerland we've got a very nice mix of Modem/ISDN, Leased Line (symmetric), Cable (256k-2M) and ADSL (256k-2M). I want to use this to tune the TCP hostcache I'm working on. The current tcp metric caching system is not very efficient (measured with the patch I posted a month ago)(this is webhost with ~200 virtual hosts, moderate traffic, uptime 13 days): net.inet.tcp.rmxcachelookup: 441942 net.inet.tcp.rmxcachehit: 49015 net.inet.tcp.rmxcacheupdate: 22696 net.inet.tcp.rmxcachenoupdate: 449336 The main culprit for the high nocacheupdate value is the requirement of 16 samples in tcp_close to update the values. In todays world with so many short lived http connections which transport only a couple of Kbytes the 16 samples are seldomly reached. The best thing would be to measure the first http/tcp connection and then use the already cached values for the following object fetch http/tcp connections. One of the focus spots I've set for the students is to find out how many samples are needed to be within 10% variation. If you have anything additional you'd like us to measure in the TCP analysis please tell me. The data we get is very valuable for data mining and reality checks. -- Andre > In place of this, I'd suggest that the slop be bumped from 200ms up to > 220ms; both linux and windows use a 200ms delayed ACK period, and we don't > want to be exactly synchronized to that time period. > > Mike "Silby" Silbersack > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D3AD843.C84F3742>