Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Feb 1999 23:10:36 -0800 (PST)
From:      Tom <tom@uniserve.com>
To:        Andrew McNaughton <andrew@squiz.co.nz>
Cc:        "Matthew D. Fuller" <fullermd@futuresouth.com>, David Kelly <dkelly@hiwaay.net>, freebsd-stable@FreeBSD.ORG
Subject:   Re: rc5des slows tape thruput 
Message-ID:  <Pine.BSF.4.02A.9902282306210.6936-100000@shell.uniserve.ca>
In-Reply-To: <199903010603.TAA09311@aniwa.sky>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Mar 1999, Andrew McNaughton wrote:

> > On Sun, Feb 28, 1999 at 09:57:44PM -0600, a little birdie told me
> > that David Kelly remarked
> > > 
> > > But Friday night was getting half this thruput. Fired up X and repeated.
> > > Essentially the same results. Then fired up rc5des, which is niced and
> > > fell to an average of 185k/sec. Snipped from top:
> > > 
> > >   294 dkelly   105  20   740K   520K RUN      9:58 97.95% 97.95% rc5des
> > 
> > One thing to bear in mind is that a process nice'd to 20 still gets CPU
> > time allotted.  I always idprio rc5des and friends.  For instance, in
> > this case, run (as root, I think you have to)
> > idprio 31 -294
> > 
> > Then it'll show up as nice 52, and ONLY use idle CPU cycles, instead of
> > having an (albeit small) slice of cycles always allocated it.
> > 
> > No, I don't think it's 'good' that nice'd to 20 it slows the tape by that
> > much, but this is at least a partial workaround (and the better way to do
> > it IMO anyway).
> 
> Does the tape process get niced also then?  Is the nice setting
> reasonable?  If not then why is rc5des allowed to slow it so much?
> 
> I don't imagine that dd to tape would need that much CPU.  I'd expect
> it to bottleneck on IO.  Is it something to do with needing very small
> chunks of CPU time and running into lots of small waits for the
> kernel's CPU time allocation?

  Maybe, maybe not.  There are device driver issues with scheduling and
CPU utilization, and with block sizes, and buffering capacity of the
driver and device.  Also an IO bound process will yield to the scheduler a
lot, and since rc5des is probably never blocked, and it will always take
slice.  If you tape requires another block at that moment, it is just
going to have to wait.

> Andrew McNaughton

Tom



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9902282306210.6936-100000>