From owner-freebsd-hackers Mon Jun 5 00:09:16 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA05835 for hackers-outgoing; Mon, 5 Jun 1995 00:09:16 -0700 Received: from mpp.com ([204.157.201.242]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA05829 for ; Mon, 5 Jun 1995 00:09:13 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id CAA04569; Mon, 5 Jun 1995 02:03:04 -0500 From: Mike Pritchard Message-Id: <199506050703.CAA04569@mpp.com> Subject: Re: why won't my tape drive keep streaming? To: tom@uniserve.com (Tom Samplonius) Date: Mon, 5 Jun 1995 02:03:04 -0500 (CDT) Cc: temp@temptation.interlog.com, hackers@freebsd.org In-Reply-To: from "Tom Samplonius" at Jun 4, 95 10:28:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1488 Sender: hackers-owner@freebsd.org Precedence: bulk > > I have the 29/28/27 cards, and 4 and 9gig Archive's. can you send me this > > test program? I'd like to try my tape drives. > > Why bother? His test program appears to duplicate what dd does already. True enough, dd if=/dev/zero of=/dev/rst0 bs=xxx count=yyy accomplishes the same thing as my test program, except that my test program actually spits out transfer rate info every 5MB for the last 5MB of data written so that I can see how bad things get when the drive stops streaming. Plus, knowing that I did have some problem, eliminating anything else that might slow things down even a little bit (e.g. having to read the data that was to be written) helped me verify that the drive would stop streaming even when data was always available to be written. I sent him the program anyways. Just a little more information: When I get the drive streaming with my test program, I can run a "dd if=/dev/rsd1a of=/dev/null" at the same time and not cause the drive to slow down at all, so it doesn't appear to be a problem with SCSI bus contention, which I thought it might be because "dump" and "tar" are both painfully slow because they hardly ever stream the drive. This is what prompted me to try and track this down, since I actually sat and waited for a dump to complete yesterday, instead of just sticking in a tape and leaving the house like I usually do. -- Mike Pritchard mpp@legarto.minn.net "Go that way. Really fast. If something gets in your way, turn"