Date: Tue, 02 Mar 1999 13:10:34 +1300 From: Andrew McNaughton <andrew@squiz.co.nz> To: Tom <tom@uniserve.com>, freebsd-stable@FreeBSD.ORG Subject: Re: rc5des slows tape thruput Message-ID: <199903020010.NAA09186@aniwa.sky> In-Reply-To: Your message of "Sun, 28 Feb 1999 23:10:36 -0800." <Pine.BSF.4.02A.9902282306210.6936-100000@shell.uniserve.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
tom@uniserve.com said: > 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. So, if rc5des is idprio'ed and the tape process blocks on IO, the rc5des process doesn't run? Or does the tape process just get control back quicker when the IO block goes away? Do you know where I could find detailed docs on this? The man pages fall short. Andrew 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?199903020010.NAA09186>