From owner-freebsd-stable@FreeBSD.ORG Wed May 11 08:27:46 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B1DE16A4CE; Wed, 11 May 2005 08:27:46 +0000 (GMT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E78E43D4C; Wed, 11 May 2005 08:27:43 +0000 (GMT) (envelope-from djv@mbnet.fi) Received: from [192.168.1.3] (GII.dsl.saunalahti.fi [85.76.233.203]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id D711FE076A; Wed, 11 May 2005 11:27:41 +0300 (EEST) Message-ID: <4281C1FC.800@mbnet.fi> Date: Wed, 11 May 2005 11:27:40 +0300 From: Tuomo Latto User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Stable References: <20050511051016.93990.qmail@web54002.mail.yahoo.com> <42819770.9070007@gmail.com> In-Reply-To: <42819770.9070007@gmail.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD current Subject: Re: xl(4) & polling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2005 08:27:46 -0000 Subhro wrote: ... > In Device Polled systems, the NIC does not generate any interrupt at > all. Instead whenever the packets arrive at a Network interface, they > are captured and put into a queue. The kernel scheduler checks the quese > at regular intervals and processes the packets which are waiting. This > interval is adjusted by the "options HZ=x" kernel option. > > If the value of x is very high, there may eb two scenarios. In the first > scenario, the queue may fill up and subsequent packets are dropped. In > this case retransmission of the packets are required. In the second > scenario, the packets would be held up for excessive long times which > defeats the entire purpose of Device Polling. If the value of x is very > low, the scheduler would check the queue frequently and would again > defeat the entire idea of Device Polling. It's the other way around. Large values indicate larger polling frequency thus amounting to more checks. Or at least the name of the option would suggest that anyway. -- Tuomo ... I can walk on water, but I stagger on alcohol