From owner-freebsd-net Sun Jul 21 8:51: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A61137B400 for ; Sun, 21 Jul 2002 08:50:57 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 13E1843E42 for ; Sun, 21 Jul 2002 08:50:56 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 71488 invoked from network); 21 Jul 2002 15:49:28 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 21 Jul 2002 15:49:28 -0000 Message-ID: <3D3AD843.C84F3742@pipeline.ch> Date: Sun, 21 Jul 2002 17:50:27 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Garrett Wollman , Jonathan Lemon , net@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_timer.h References: <20020719134639.S95326-100000@patrocles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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