From owner-freebsd-questions@FreeBSD.ORG Mon Mar 28 18:14:55 2005 Return-Path: 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 422B216A4CE for ; Mon, 28 Mar 2005 18:14:55 +0000 (GMT) Received: from smtp11.wanadoo.fr (smtp11.wanadoo.fr [193.252.22.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8A0343D2D for ; Mon, 28 Mar 2005 18:14:54 +0000 (GMT) (envelope-from atkielski.anthony@wanadoo.fr) Received: from me-wanadoo.net (unknown [127.0.0.1]) by mwinf1108.wanadoo.fr (SMTP Server) with ESMTP id 36DC91C00050 for ; Mon, 28 Mar 2005 20:14:53 +0200 (CEST) Received: from pix.atkielski.com (ASt-Lambert-111-2-1-3.w81-50.abo.wanadoo.fr [81.50.80.3]) by mwinf1108.wanadoo.fr (SMTP Server) with ESMTP id 015D81C000B9 for ; Mon, 28 Mar 2005 20:14:52 +0200 (CEST) X-ME-UUID: 20050328181453579.015D81C000B9@mwinf1108.wanadoo.fr Date: Mon, 28 Mar 2005 20:14:52 +0200 From: Anthony Atkielski X-Priority: 3 (Normal) Message-ID: <1873266905.20050328201452@wanadoo.fr> To: freebsd-questions@freebsd.org In-Reply-To: <8C701C5A7BE6FEE-4B8-3F7A1@mblk-d50.sysops.aol.com> References: 6667 <20050328142522.40982.qmail@web90210.mail.scd.yahoo.com> <1802825135.20050328164920@wanadoo.fr> <8C701C5A7BE6FEE-4B8-3F7A1@mblk-d50.sysops.aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: hyper threading. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-questions@freebsd.org List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 18:14:55 -0000 em1897@aol.com writes: > Things have changed a bit since then, so I doubt that > "proof" has any relevance. The principles haven't changed at all. Servicing interrupts is an extremely high-overhead activity. There's a minimum amount of time it takes, no matter how short the interrupt routine. There comes a point when just the inherent cost of the context switch is responsible for most of the overall cost of the interrupt service, and with a large number of interrupts, the processor(s) can spend a great deal of time just switching contexts. Polling eliminates this overhead by simply checking for I/O to service when it is convenient for the OS. As long as polls occur frequently enough not to miss any pending I/O, it's faster than interrupt-driven I/O. The total number of instructions executed is often greater, because the OS tends to spin on its polling tasks, but the absolute time required to respond to a given I/O event can be much shorter. In my case, I divided all the work of the comm program into small bits that could be done in tiny chunks. Each time a chunk was completed, I polled the serial port. Since chunks never exceeded a certain size, I always managed to poll the port in less time than it took to receive a character, even at 38,400 bps. The system was busier than it would be with interrupts driving it, but it responded more quickly to incoming traffic, and there were no transfer timeouts, whereas with interrupts, the system was less busy, but it timed out very consistently at high communications rates. By using more processor but evening out the use of processor so that it was more consistently distributed, very high communication rates could be handled by the program. All of this remains permanently applicable today, and it is why some high-speed applications poll instead of waiting for interrupts. -- Anthony