From owner-freebsd-sparc64@FreeBSD.ORG Thu Nov 30 22:24:58 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F099516A40F for ; Thu, 30 Nov 2006 22:24:58 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [69.31.131.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4509943CCE for ; Thu, 30 Nov 2006 22:24:34 +0000 (GMT) (envelope-from carton@Ivy.NET) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [69.31.131.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id 71B482FF63 for ; Thu, 30 Nov 2006 17:24:44 -0500 (EST) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id A1B2012FB03; Thu, 30 Nov 2006 17:24:43 -0500 (EST) To: freebsd-sparc64@freebsd.org References: <755cb9fc0611290724q127f006va84f3457c48443b6@mail.gmail.com> <456E8D8B.8010102@orel.ru> <755cb9fc0611300454s4d28ad14rd402cba8388d49@mail.gmail.com> <14989d6e0611300700n3ac073bayc4584f2b1020ee61@mail.gmail.com> <755cb9fc0611300839y6deed1ceqf452018cc2f73737@mail.gmail.com> <755cb9fc0611301208w1ff93987m88885b3b59444373@mail.gmail.com> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Nov_30_17:24:34_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 30 Nov 2006 17:24:43 -0500 In-Reply-To: <755cb9fc0611301208w1ff93987m88885b3b59444373@mail.gmail.com> (Alexandre Vieira's message of "Thu, 30 Nov 2006 20:08:46 +0000") Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: Netra T1 105 (sparc64) optimization X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2006 22:24:59 -0000 --pgp-sign-Multipart_Thu_Nov_30_17:24:34_2006-1 Content-Type: text/plain; charset=US-ASCII >>>>> "av" == Alexandre Vieira writes: av> Without polling it transfers like 8MB/s, with polling it does av> less than this and there is twice the latency. that's not what i expected on both counts. but the supposed benefit of polling is increase in pps capacity, not reduced latency. In theory, it is supposed to operate normally with interrupts enabled for small-packets-per-second loads, giving the same latency as without polling. For your ping test where the bridge is presumably idle except for the ping, I'd expect that---interrupt mode, and the same latency as without polling. Somewhere around 1 - 10kpps it should switch to polling and collect batches of 1ms of packets on each timer interrupt, giving you <= 1ms additional latency (HZ=1000) compared to without polling. In exchange for the added latency, the CPU load should be lower, and the max pps it can handle before dropping packets should be greater. Again the tradeoff should only happen under load, not just an idle line except ping. polling is mostly about high pps, so that would be either gigabit without jumboframes, or 100Mbit/s with small packets (VoIP or DDoS). so for 100Mbit/s and big packets like FTP I'm not surprised that you see no benefit, but I would still have expected the transfer speed with polling to be either unaffected or better. ...guess it's not what I expected. :) --pgp-sign-Multipart_Thu_Nov_30_17:24:34_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUARW9aK4nCBbTaW/4dAQInhwP8D8TiR31b8XdnVO6DHGJGDzoW7amjNquN NvLPOS2tR8Bhp4fYjZXW8s6dFqenCs3wDKEM9/MjO10urmiMUhs26+XcC2qnNw/j O6KFy+EtS5NMkIg6K5tDzbaYcuT2074kdqlyNbioU/lnjve5Vk/7PjW3XdMGYuRY s/XxpyyNmMc= =Y7dT -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Nov_30_17:24:34_2006-1--