Date: Mon, 01 Mar 1999 19:03:40 +1300 From: Andrew McNaughton <andrew@squiz.co.nz> To: "Matthew D. Fuller" <fullermd@futuresouth.com> Cc: David Kelly <dkelly@hiwaay.net>, freebsd-stable@FreeBSD.ORG Subject: Re: rc5des slows tape thruput Message-ID: <199903010603.TAA09311@aniwa.sky> In-Reply-To: Your message of "Sun, 28 Feb 1999 22:52:43 MDT." <19990228225243.W3203@futuresouth.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? Andrew McNaughton 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?199903010603.TAA09311>