From owner-freebsd-stable Mon Feb 1 10:28:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA24569 for freebsd-stable-outgoing; Mon, 1 Feb 1999 10:28:03 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from destiny.erols.com (destiny.erols.com [207.96.73.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA24521 for ; Mon, 1 Feb 1999 10:28:00 -0800 (PST) (envelope-from jdowdal@destiny.erols.com) Received: from destiny.erols.com (someone@destiny.erols.com [207.96.73.65]) by destiny.erols.com (8.9.2/8.6.12) with ESMTP id NAA16543; Mon, 1 Feb 1999 13:27:46 -0500 (EST) Date: Mon, 1 Feb 1999 13:27:45 -0500 (EST) From: John Dowdal To: Stormy Henderson cc: stable@FreeBSD.ORG Subject: Re: network slowdown with rc5des In-Reply-To: <19990201111258.A89636@rain.futuresouth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 1 Feb 1999, Stormy Henderson wrote: > A happy camper (John Dowdal, jdowdal@destiny.erols.com) once wrote... > > There is a dramatic network slowdown on 3.0-stable when usign 100BT > > cards and rc5des at the same time. The rc5des process causes the > > slowdown even if it is set to idprio 1. > > I think you have the priority backwards (or didn't type the 3 hard > enough). The manpage for idprio states: > > Priority is an integer between 0 and RTP_PRIO_MAX (usually 31). 0 is > the highest priority > > Be happy... I did idprio 1 -PID, where PID is the PID of the rc5des job. IT worked, because the rc5des process shows up with a nice value of 22. Also from the idprio man page: A process with an idle priority will run only when no other process is runnable and then only if its idle priority is equal or greater than all other runnable idle priority processes. This should imply that it doesn't matter whether I use 1 or 31 for priority, because I do not have any other processes with idle priority. Based on the behavior (and not te sources), it appears that the ethernet-card-is-ready interrupt is placed into a queue to be scheduled later, instead of immediately preempting the idprio processes. IT also appears that the interrupt will preempt the kernel idle loop causing better performance if I kill -STOP the rc5des process. The big question is why the system behaves differently when its executing a idprio job and its internal idle loop. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message