Date: Mon, 01 Mar 1999 20:44:51 -0600 From: David Kelly <dkelly@hiwaay.net> To: Andrew McNaughton <andrew@squiz.co.nz> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: rc5des slows tape thruput Message-ID: <199903020244.UAA02047@nospam.hiwaay.net> In-Reply-To: Message from Andrew McNaughton <andrew@squiz.co.nz> of "Mon, 01 Mar 1999 19:03:40 %2B1300." <199903010603.TAA09311@aniwa.sky>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew McNaughton writes: > > Does the tape process get niced also then? No. > Is the nice setting reasonable? Yes. > If not then why is rc5des allowed to slow it so much? The picture that I'm getting is a single block is written to the tape drive at a time. When the tape drive is ready for another block rc5des's current time slice is not aborted but allowed to complete before dd gets a time slice to queue another block to the tape. The drive at home has 1M of internal RAM, the DDS-3 drives at work have 2M buffers. It would appear FreeBSD doesn't make use of these buffers. > 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 t ime and running into lots of small waits for the > kernel's CPU time allocation? A couple of percent. Using dd to read /dev/zero and write /dev/null yields 208M/sec w/o rc5des running, 203M/sec with, writing 100000 blocks of 10k (roughly 1G) so the test runs long enough to be valid. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. 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?199903020244.UAA02047>