From owner-freebsd-questions@FreeBSD.ORG Sun Aug 21 15:38:44 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 0428F16A41F for ; Sun, 21 Aug 2005 15:38:44 +0000 (GMT) (envelope-from danial_thom@yahoo.com) Received: from web33304.mail.mud.yahoo.com (web33304.mail.mud.yahoo.com [68.142.206.119]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F0AD43D45 for ; Sun, 21 Aug 2005 15:38:43 +0000 (GMT) (envelope-from danial_thom@yahoo.com) Received: (qmail 89863 invoked by uid 60001); 21 Aug 2005 15:38:43 -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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kc57eRIQm/qWaRohLR2Hu77EcwTe5S41EuBUzIxZRAUHh+2PVvI8B6emoWDx8NhdXqZIyZuAtX14CvUgW7SQgghJra0Gr16wERcaGXzHNQpmhEDz8yXB2hRWaVxbsNElNJL/0S0+ONVD7V6IxU3uSnmsjkpXN7NOPCyIQpvKkEc= ; Message-ID: <20050821153843.89861.qmail@web33304.mail.mud.yahoo.com> Received: from [69.114.187.133] by web33304.mail.mud.yahoo.com via HTTP; Sun, 21 Aug 2005 08:38:43 PDT Date: Sun, 21 Aug 2005 08:38:43 -0700 (PDT) From: Danial Thom To: Garrett Cooper , freebsd-questions@freebsd.org In-Reply-To: <430894AA.8060605@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: polling decreases throughput ~50% 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: Sun, 21 Aug 2005 15:38:44 -0000 --- Garrett Cooper wrote: > Danial Thom wrote: > > >--- Victor Semionov 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