Date: Sun, 21 Aug 2005 08:38:43 -0700 (PDT) From: Danial Thom <danial_thom@yahoo.com> To: Garrett Cooper <youshi10@u.washington.edu>, freebsd-questions@freebsd.org Subject: Re: polling decreases throughput ~50% Message-ID: <20050821153843.89861.qmail@web33304.mail.mud.yahoo.com> In-Reply-To: <430894AA.8060605@u.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Garrett Cooper <youshi10@u.washington.edu> wrote: > Danial Thom wrote: > > >--- Victor Semionov <victor@vmpbg.com> wrote: > > > > > > > >>>>>Why is that? I thought polling should > >>>>> > >>>>> > >>decrease CPU usage by avoiding too > >> > >> > >>>>>many context switches when a hw irq is > >>>>> > >>>>> > >>generated frequently, but it > >> > >> > >>>>>shouldn't make the transfer slower if > >>>>> > >>>>> > >>there are no other jobs running. > >> > >> > >>>You have to poll often enough to keep the > >>> > >>> > >>pipe full, otherwise your max > >> > >> > >>>throughput can be limited. Also, rl > hardware > >>> > >>> > >>isn't the greatest and > >> > >> > >>>probably requires a lot more CPU than a > >>> > >>> > >>device with working buffer/DMA > >> > >> > >>>design. > >>> > >>> > >>HZ is 1000, which I guess should be more than > >>enough with > >>kern.polling.burst_max=150. > >> > >>Indeed, it was hardware's fault - my other > NIC > >>is a fxp and I got much better > >>results with it - less CPU, while throughput > >>stayed the same as without > >>polling. > >> > >> > > > >Great. So you've added 900 totally unnecessary > >context switches, plus all of the rubbish that > >gets done every clock tick, even when there is > no > >traffic. Brilliant. > > > >Modern hardware doesn't interrupt every > packet; > >in fact with intel em controllers its easily > >tunable, so you get the advantages of polling > >without the disadvantages of having a system > >designed by an idiot. Polling will cause you > to > >lose tons of packets under bursts of heavy > load. > >Although it is downright comical that you're > >concerned about cpu cycles but you were using > the > >slowest, least efficient ethernet controller > ever > >conceived. > > > >The fxp driver has a built-in hold off of 6000 > >ints/sec (which is 1/6000th of a second for > you > >mathletes). There is no reason to use polling > >with intel hardware; in fact its a big > negative. > > > >Danial > > > Heh. We just discussed polling vs > interrupts in an embedded systems > class this past quarter. Interrupts are better > for more intermittent use > and polling is better for more frequent use, as > polling is actually a > deadloop of course-for checking a flag most of > the time-with potentially > a lot of wasted clock cycles before a context > switch is made and the > task that was being polled for is run. Also, > considering that actual > computer hardware isn't going to be running > 100% of the time (except for > the CPU running idle tasks and stuff), > interrupts are by far the better > way to go in general. But yeah... too many > interrupts are bad as well... > Anyhow, that was sidetracking a bit :). > -Garrett The problem with a "discussion" is that IQ isn't cumulative. So if no one in the discussion has a clue, then the conclusions don't mean much. If you argue the merits of polling based on wrong information (like the assumption that you'll get a hardware interrupt for each event), then you've just wasted a lot of time and learned nothing. You seem to have missed the point that hardware has hold-offs that negate ANY need for polling. Polling is a non-solution to a non-problem in the modern world. Danial __________________________________________________ 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?20050821153843.89861.qmail>