From owner-freebsd-questions@FreeBSD.ORG Sun Aug 21 14:50:56 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 98FDC16A41F for ; Sun, 21 Aug 2005 14:50:56 +0000 (GMT) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E7743D49 for ; Sun, 21 Aug 2005 14:50:56 +0000 (GMT) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j7LEotrk021650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 21 Aug 2005 07:50:55 -0700 X-Auth-Received: from [140.142.179.57] (cs333-56.spmodem.washington.edu [140.142.179.57]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.07) with ESMTP id j7LEon7C010037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 21 Aug 2005 07:50:53 -0700 Message-ID: <430894AA.8060605@u.washington.edu> Date: Sun, 21 Aug 2005 07:50:18 -0700 From: Garrett Cooper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <20050821123959.56599.qmail@web33304.mail.mud.yahoo.com> In-Reply-To: <20050821123959.56599.qmail@web33304.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: polling decreases throughput ~50% 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: Sun, 21 Aug 2005 14:50:56 -0000 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