From owner-freebsd-questions@FreeBSD.ORG Wed Dec 14 08:53:27 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 7F20416A41F for ; Wed, 14 Dec 2005 08:53:27 +0000 (GMT) (envelope-from tedm@toybox.placo.com) Received: from mail.freebsd-corp-net-guide.com (mail.web-strider.com [65.75.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C9743D46 for ; Wed, 14 Dec 2005 08:53:26 +0000 (GMT) (envelope-from tedm@toybox.placo.com) Received: from tedwin2k (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.11.1/8.11.1) with SMTP id jBE8pOb05920; Wed, 14 Dec 2005 00:51:24 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: , "Drew Tomlinson" Date: Wed, 14 Dec 2005 00:48:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20051213190711.25141.qmail@web33313.mail.mud.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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 List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2005 08:53:27 -0000 >-----Original Message----- >From: owner-freebsd-questions@freebsd.org >[mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Danial Thom >Sent: Tuesday, December 13, 2005 11:07 AM >To: Drew Tomlinson >Cc: freebsd-questions@freebsd.org >Subject: Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme >Song) > > > > >--- 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. > Well, if polling does no good for fxp, due to the hardware doing controlled interrupts, then why does the fxp driver even let you set it as an option? And why have many people who have enabled it on fxp seen an improvement? I've read those datasheets as well and the thing I don't understand is that if you are pumping 100Mbt into an Etherexpress Pro/100 then if the card will not interrupt more than this throttled rate you keep talking about, then the card's interrupt throttling is going to limit the inbound bandwidth to below 100Mbt. In which case this is not a 10/100 card and Intel is guilty of false advertising and so on, plus nobody would ever report that they could actually get 100Mbt of bandwidth on this card. In other words, a few moments logical thinking would show that this throttling is worthless at high bandwidth and only is going to work at lower bandwidth, where polling overhead is a net lose anyway. >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. > Here we go again with the hand-waving. Did it ever occur to you to post the actual machine specs of the systems involved? Ted >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 >_______________________________________________ >freebsd-questions@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-questions >To unsubscribe, send any mail to >"freebsd-questions-unsubscribe@freebsd.org" > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.1.371 / Virus Database: 267.13.13/199 - Release >Date: 12/13/2005 >