From owner-freebsd-hackers Thu Jan 31 18:33: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 04DFB37B402 for ; Thu, 31 Jan 2002 18:33:00 -0800 (PST) Received: from pool0359.cvx40-bradley.dialup.earthlink.net ([216.244.43.104] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16WTVP-0000JV-00; Thu, 31 Jan 2002 18:32:48 -0800 Message-ID: <3C59E873.4E8A82B5@mindspring.com> Date: Thu, 31 Jan 2002 16:59:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Storms of Perfection , thierry@herbelot.com, replicator@ngs.ru, hackers@FreeBSD.ORG Subject: Re: Clock Granularity (kernel option HZ) References: <20020131172729.X38382-100000@patrocles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@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: > The TCP stack, on the other hand, is perfectly happy with 10ms resolution. > Retransmission timeouts are only actually used when loss occurs on the > network, and 10ms is more than accurate enough for retransmission. (I > believe that retransmit timeouts are rounded up to 1 second, but don't > quote me on that.) The other timed events (keepalive timeouts, delayed > ack timeouts, etc) are also in good shape with 10ms accuracy. You will get a factor of 6 (approximately) improvement in throughput vs. overhead if you process packets to completion at interrupt, and process writes to completion at write time from the process. Running through NETISR introduces a dequeueing latency that adds incredible latency overhead. I was able to triple the connnections per second rate, to about 22,000, without a SYN cache, by processing this way, and that's running them fully up to the creation of the socket: it's not some fake to-the-stack number that can't be used for useful work without more work that's not counted in the sampling. See the Rice University paper on LRP. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message