From owner-freebsd-stable@FreeBSD.ORG Wed May 11 05:26:37 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 E611416A4D0 for ; Wed, 11 May 2005 05:26:37 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C62243D73 for ; Wed, 11 May 2005 05:26:37 +0000 (GMT) (envelope-from subhro.kar@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so11868rng for ; Tue, 10 May 2005 22:26:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type; b=FknvDLysTV0TgpSK3Wxjl+Bxel6Opfb5orUKzhp+VAPIXrhRi8OrZiRPGhQaswEytMudjXyQGZIfA+4DKgczzZbOPpBZ2TQweca1i9XiIJ8RkGireUIzv5Q5ZwpKs9QxoWtYobZkc2MQGurme42jTQrdkjVBbdHEhWvKvRA3qdQ= Received: by 10.38.71.62 with SMTP id t62mr55323rna; Tue, 10 May 2005 22:26:36 -0700 (PDT) Received: from ?59.93.162.113? ([59.93.162.113]) by mx.gmail.com with ESMTP id h17sm1621909rnb.2005.05.10.22.26.23; Tue, 10 May 2005 22:26:36 -0700 (PDT) Message-ID: <42819770.9070007@gmail.com> Date: Wed, 11 May 2005 10:56:08 +0530 From: Subhro Organization: Indian Institute of Information Technology User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob References: <20050511051016.93990.qmail@web54002.mail.yahoo.com> In-Reply-To: <20050511051016.93990.qmail@web54002.mail.yahoo.com> Content-Type: multipart/mixed; boundary="------------040402080605000400060602" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: FreeBSD Stable cc: FreeBSD current cc: ru@FreeBSD.org 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 05:26:38 -0000 This is a multi-part message in MIME format. --------------040402080605000400060602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/11/2005 10:40, Rob wrote: >--- Subhro wrote: > > > >>On 5/11/2005 8:04, Rob wrote: >> >> >> >>>All computers are running 5-Stable, as of May 10. >>>All, but PC1 with fxp, use polling, with: >>> options DEVICE_POLLING >>> options HZ=1000 >>> >>> >>1000 IMHO seems a bit too heavy. Try something >>lower. >> >> > >What is heavy and what is not? >Does 100 sound better? > >How can I develop a feeling for the 'heaviness' of >this HZ number? Is it related to the CPU speed? > >Thanks for clarifying! > >Rob. > > > Before I answer this question, I would like to clarify a few things. Previously (when there was no concept of Device Polling) whenever a packet arrived at a network interface, the NIC generated an interrupt. An interrupt would cause the processor to stop whatever it was doing and make it look into the reason why the interrupt was generated. This concept had no problems except the fact that it could be used maliciously. For example, if someone wants to consume all processing power, he may create an interrupt storm by constanly sending packets to the NIC. the NIC would continue generating interrupts and the processor would be busy servicing them, thus wasting and depriving other processes from precious CPU cycles. This is one form of Denial of Service attack. Also for systems which handle really heavy loads, a legal series of interrupts may seem like a DOS. Thus the concept of Device Polling came into play 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. The value of x is very much implementation and load specific. When I have to put up a new FreeBSD box, I start from 100 and start beefing up the number until I find a good balance. For your implementaion it seems to me as if the packets are waiting in the queue for a long time which are causing the SSH sessions to time out. Regards S. --------------040402080605000400060602--