From owner-freebsd-questions@FreeBSD.ORG Sun Aug 21 12:40:00 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 57B7916A41F for ; Sun, 21 Aug 2005 12:40:00 +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 EE32543D53 for ; Sun, 21 Aug 2005 12:39:59 +0000 (GMT) (envelope-from danial_thom@yahoo.com) Received: (qmail 56601 invoked by uid 60001); 21 Aug 2005 12:39:59 -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=JWfFTIECByzLzm2jdTu10lVikAp3Bu37rviqesHJxx/Nbws/pMn8sOhYEBTe8VthVkzYbbcB4mV+6rkJbADhH0Dpe7R5sNlsOKxwZbzE+LK9meyTJiUp1abO2wTs7MO/89fg4SR36MnOA7Eew0yxinGx7MbVSYRZRQvPd9WRfIE= ; Message-ID: <20050821123959.56599.qmail@web33304.mail.mud.yahoo.com> Received: from [69.114.187.133] by web33304.mail.mud.yahoo.com via HTTP; Sun, 21 Aug 2005 05:39:59 PDT Date: Sun, 21 Aug 2005 05:39:59 -0700 (PDT) From: Danial Thom To: Victor Semionov , Chuck Swiger , freebsd-questions@freebsd.org In-Reply-To: <200508031223.20065.victor@vmpbg.com> 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 12:40:00 -0000 --- 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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com