Date: Tue, 13 Dec 2005 00:44:35 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Drew Tomlinson" <drew@mykitchentable.net> Cc: Michael Vince <mv@roq.com>, danial_thom@yahoo.com, freebsd-questions@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: RE: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song) Message-ID: <LOBBIFDAGNMAMLGJJCKNGEADFDAA.tedm@toybox.placo.com> In-Reply-To: <439DDDDB.2080902@mykitchentable.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----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. >Not sure if 100 mbps is >considered "high" or "low" speed. I'm specifically interested in >NetGear cards using the dc driver or DLink cards using the rl driver. > The rl chipset isn't known as a very good chipset. YMMV Some of the Netgear cards use clone 21143 chipsets which are extremely inferior to the real thing. In particular if your Netgear card is using a PNIC chipset it is pretty bad with serious performance penalty. This is documented in Section 4 of the dc manpage. People seem to have good results with polling on the fxp cards. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNGEADFDAA.tedm>