From owner-freebsd-questions@FreeBSD.ORG Tue Dec 13 19:07:22 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30B5616A41F for ; Tue, 13 Dec 2005 19:07:22 +0000 (GMT) (envelope-from danial_thom@yahoo.com) Received: from web33313.mail.mud.yahoo.com (web33313.mail.mud.yahoo.com [68.142.206.128]) by mx1.FreeBSD.org (Postfix) with SMTP id 80C4843D82 for ; Tue, 13 Dec 2005 19:07:12 +0000 (GMT) (envelope-from danial_thom@yahoo.com) Received: (qmail 25143 invoked by uid 60001); 13 Dec 2005 19:07:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1msIKfbZipQ7Aujz+bA2iwZoBvHQ6wUkkiHoWlHXgsWvQsXn9lh1hziKAhGuu0uqxGYvcfNzpzpmiiJZLXeZIidoI1rX2Kl/E3yPvZaPpX4JHC7ujXta27f7D9QRjflPj1RXiVXbVw1lvewz1vve8Z/WQ1aDHSeuCFGDkQERs04= ; Message-ID: <20051213190711.25141.qmail@web33313.mail.mud.yahoo.com> Received: from [24.46.186.215] by web33313.mail.mud.yahoo.com via HTTP; Tue, 13 Dec 2005 11:07:11 PST Date: Tue, 13 Dec 2005 11:07:11 -0800 (PST) From: Danial Thom To: Drew Tomlinson In-Reply-To: <439EDF2D.2050701@mykitchentable.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-questions@freebsd.org Subject: Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: danial_thom@yahoo.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2005 19:07:22 -0000 --- Drew Tomlinson wrote: > Ted Mittelstaedt wrote, On 12/13/2005 12:44 AM: > > > > > > >>-----Original Message----- > >>From: Drew Tomlinson > [mailto:drew@mykitchentable.net] > >>Sent: Monday, December 12, 2005 12:30 PM > >>To: Ted Mittelstaedt > >>Cc: Michael Vince; danial_thom@yahoo.com; > freebsd-questions@freebsd.org; > >>Kris Kennaway > >>Subject: Polling For 100 mbps Connections? > (Was Re: Freebsd Theme Song) > >> > >> > >>On 12/12/2005 8:13 AM Ted Mittelstaedt wrote: > >> > >> > >> > >>>Michael, > >>> > >>> Fundamentally, here's the problem Danial is > claiming exists: > >>> > >>>it takes a certain amount of time to get the > packet clocked in > >>> > >>> > >>>from the network into the ethernet receiver. > This is hardware > >> > >> > >>>dependent and cannot be changed. > >>> > >>>It takes a certain amount of time to get the > packet out of > >>>the hardware in the ethernet card into main > ram, this also > >>>hardware dependent and cannot be changed. > (unless the device > >>>driver is terribly inefficient, which we > will assume it's not) > >>> > >>>Once in main ram, the information in the > packet has to go through > >>>a number of code statements. The more code > statements the > >>>longer the information in the packet is > sitting around in > >>>the FreeBSD system's memory. > >>> > >>>It then takes a certain amount of time to > get the information > >>>out of main memory into the other sending > ethernet nic's buffers, > >>> > >>>and it takes time to get it out of the > sending nic back to the > >>>wire. > >>> > >>>Danial is claiming the slowness is in the > main ram section of > >>>things, not in the ethernet driver code. > >>> > >>>polling makes the ethernet driver more > efficient at high data > >>>rates, but it does nothing for the speed of > processing within > >>>the TCPIP stack itself. At low data rates > polling is less > >>>efficient than the interrupt method. And > unless the nic driver > >>>is terribly inefficient to start with, the > time it adds to the > >>>packet path in the system is minor compared > to the time spent > >>>in the TCP/IP stack. > >>> > >>>Ted > >>> > >>> > >>> > >>> > >>Thanks for the explanation. So would polling > be beneficial or > >>detrimental for a 100 mbps Ethernet card? > >> > >> > > > >Yes, if you were running 100Mbt's of bandwidth > through it. > > > > > > I assume you mean "yes it's beneficial"? :) Thats just not true, or at least not globally. The right answer is: It depends on the hardware. Polling should NEVER be used for hardware that has built-in hardware interrupt throttling (such as fxp and em driver cards). polling has a LOT of overhead. Hardware hold offs give you the benefit of controlled interrupt reduction without adulterating your system with tons of extra clock interrupts. This has been discussed over and over, and still some of the people who are supposed to know about this have no clue whatsoever. polling is ONLY a POSSIBLE advantage is your hardware actually interrupts for every event. Good controllers do not. I don't know the specs of every card/chipset, but with intel cards you definitely do NOT want to use polling, as an example. Regardless of the hardware, if you see a substantial increase with performance its because the OS is broken and not because of the polling, particularly if you have a relatively low volume of traffic. The same number of cpu cycles are needed to process the packets whether you poll or not. As an example, changing the number of receive interrupts per second from 10,000 to 25000 on an em card (4.9 OS, which is known NOT to be broken) pushing 100Kpps yields about a 3% difference in cpu load (no noticable difference in performance). For an average load server doing less than 1K pps, on a modern processor the cpu load difference is not significant enough to make much noticable difference in performance. Of course anyone using a realtek or cheap controller on an expensive machine is just a plain fool; spend the extra relative pennies for a controller that actually works properly. I'm amazed at the number of idiots running MP machines with cheap ethernet controllers. Its like putting $25. tires on a porche. DT __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com