Date: Wed, 14 Dec 2005 11:13:32 -0800 (PST) From: Danial Thom <danial_thom@yahoo.com> To: Ted Mittelstaedt <tedm@toybox.placo.com>, Drew Tomlinson <drew@mykitchentable.net> Cc: freebsd-questions@freebsd.org Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) Message-ID: <20051214191332.42237.qmail@web33311.mail.mud.yahoo.com> In-Reply-To: <LOBBIFDAGNMAMLGJJCKNAEAIFDAA.tedm@toybox.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Ted Mittelstaedt <tedm@toybox.placo.com> wrote: > > > >-----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 <drew@mykitchentable.net> > >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? They haven't, freebsd accounting doesn't work properly with polling enabled, and "they" don't have the ability to "know" if they are getting better performance, because "they", like you, have no clue what they're doing. How about all the idiots running MP with FreeBSD 4.x, when we know its just a waste of time? "they" all think they're getting worthwhile performance, because "they" are clueless. Maybe its tunable because they guy who wrote the driver made it a tunable? duh. I've yet to see one credible, controlled test that shows polling vs properly tuned interrupt-driven. The only advantage of polling is that it will drop packets instead of going into livelock. The disadvantage is that it will drop packets when you have momentary bursts that would harmlessly put the machine into livelock. Thats about it. > > 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. Wrong again, Ted. It scares me that you consider yourself knowlegable about this. You can process #interrupts X ring_size packets; not one per interrupt. You're only polling 1000x per second (or whatever you have hz set to), so why do you think that you have to interrupt for every packet to do 100Mb/s? Do you not understand that packet processing is the same whether its done on a clock tick or a hardware interrupt? Do you not understand that a clock tick has more overhead (because of other assigned tasks)? Do you not understand that getting exactly 5000 hardware interrupts is much more efficient than having 5000 clock tick interrupts per second? What part of this don't you understand? DT __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051214191332.42237.qmail>