From owner-freebsd-stable Mon Mar 1 20: 0:12 1999 Delivered-To: freebsd-stable@freebsd.org Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by hub.freebsd.org (Postfix) with SMTP id AF45314C34 for ; Mon, 1 Mar 1999 20:00:00 -0800 (PST) (envelope-from tom@uniserve.com) Received: from shell.uniserve.ca [204.244.186.218] by pop.uniserve.com with smtp (Exim 1.82 #4) id 10HgLH-00034h-00; Mon, 1 Mar 1999 19:59:35 -0800 Date: Mon, 1 Mar 1999 19:59:32 -0800 (PST) From: Tom X-Sender: tom@shell.uniserve.ca To: David Kelly Cc: Andrew McNaughton , freebsd-stable@FreeBSD.ORG Subject: Re: rc5des slows tape thruput In-Reply-To: <199903020244.UAA02047@nospam.hiwaay.net> 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 Mar 1999, David Kelly wrote: > 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 see how that could be. SCSI tapes are SCSI tapes. Any buffering done by the device should be invisible. There might be a SCSI mode page flag to turn it on or off though. > > 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. Those figures are pretty weird. 208MB/s or ? That is a pretty fast tape drive. /dev/zero isn't a good test source due to drive compression and encoding stuff. > -- > 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 > > Tom Systems Support Uniserve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message