Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mitel!sce!nrcaer!fts1!michael
From: michael@fts1.UUCP (Michael Richardson)
Newsgroups: comp.unix.i386
Subject: Re: ulimit hassles
Summary: Is dd that good?
Message-ID: <135@fts1.UUCP>
Date: 10 Feb 90 01:49:25 GMT
References: <1611@aber-cs.UUCP>
Reply-To: michael@fts1.UUCP (Michael Richardson)
Followup-To: comp.unix.i386
Organization: Fountain Technical Services, Ottawa, ON
Lines: 24

In article <1611@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>You should be using 'ddd' (which has been posted to
>comp.sources.misc) or, even faster, my own 'team' (which has
>been posted to alt.sources; a slightly improved version will be


	Now, I haven't tried `team', so I can't comment on that, but I did run some 
preliminary tests with ddd vs SVR3.2 (ICS 386/ix) dd, and found that there
was a negligible difference between the two.
	I have not gotten around to doing disk to disk tests, I started with 
{dd/ddd} if=/dev/rmt0 of=junk and of=/dev/null with block sizes varying from 
200k down to 1k. The tape (an AT style Archive tape controller in an AMI386
Mark II motherboard) had about 10meg of stuff on it. (Had to up the ulimit 
to run the tests :-) )
	ddd seemed to occasionally change the file mode to 000, and then die on the
next write. I never did track this down. Is it possible that the tape controller
was the critical factor, and ddd does many times better on disk to disk? Or writes
to the drive?

-- 
  :!mcr!:
  Michael C. Richardson
HOME: mcr@julie.UUCP SCHOOL: mcr@doe.carleton.ca WORK: michael@fts1.UUCP
I never liked staying in one place too long, but this is getting silly...