masaru@media-lab.media.mit.edu.MEDIA.MIT.EDU (Masaru Sugai) (04/22/91)
In article <61897@masscomp.westford.ccur.com> mark@calvin.westford.ccur.com (Mark Thompson) writes: >In article <1991Apr13.014520.13657@sugar.hackercorp.com> ssd@sugar.hackercorp.com (Scott Denham) writes: >>Does anyone recognize these symptoms? >> I'm running BTNTape 2.0 on an A2000 / A2090A to a Cipher 540 1/4" tape >>drive. I can get TAR to read from the drive, but after some >>(variable) number of blocks are read, the system locks up solid. > >Yes, I have seen the same thing. I was using BTNTape 2.0 with a 525 Meg >Archive 1/4" tape drive in a 2500/30 with a 2091. When I ran with the >default handler setups, it would take a while to lock, but when it was >optimized for speed with my drive, lockup would occur quite quickly. >I hope someone can answer how to fix this since the new BTN is about 4x >faster than BRU with my configuration and I desparately need FAST archiving. I third them :) I've been frustrated with my A3090 (C= 150MB QIC) I picked up yesterday. I hooked it up to A3000/16, and was easy to take a full backup of WORK: using BRU w/o any problems. All I had to do were moving tape: entry to the top of BRUtab file, then "bru -c" at the root directory. That's it. Encouraged with this success, I then tried TAR+MWtape from fish #440s, and it ruined my Saturday night! I had to check several FTP sites, CIS, and BIX to get ARP mount command which MWtape requires, but no avail. I gave up MWtape and went to BTN. BTN seems quite useful, especially its tapemon tool is wonderful as it shows what's going on in tape drives. But there are several glitches. - I could store and restore files only when I set tape buffer to 512B long. Buuut, it's slow (say, 15KB/sec) and consumes most of tape for block gaps! Nearly 80% of tape has used to just save 30MB. - With buffer size over 1024B or more, TAR seems to write all data on tape. Archiving speed is around 90KB/sec when I set buffer size to 64KB, acceptable performance, judging from A3090 transfer rate (112.5KB/sec). This is an option for a write-only mode, though. I can read, say, first megs, but as soon as I hit upon a large file (a few hudred kilobytes), TAR quits with Tapemon's "SELECTION TIMEOUT ERROR" message. I am better off than they are, as I am free from lockup and guru SO FAR. I know what BTN stands for, but it is a decent implementation of tape driver on standard Amiga configuration. It would be a BTA with a little bit more of error handling... Any idea ? BTW, does anybody have working experience of TAR to exchange data with UNIX ? I have no idea what is the most appropriate block size, as A3090 has nothing technical on its booklet. Is there any preferred block size for each UNIX ? Finally to A3090 owners: what are 'buttons' stapled on the installation guide for ? Are they edible ? -- Masaru Sugai -- -- Masaru Sugai:Use disclaimer. CIS 72050,2141:NeXT + A3000 = money-eater NEC Corporation:sugai@ccs.mt.nec.co.jp DORMANT:hardwired logic,machine language MIT R.Affiliate:masaru@media-lab.media.mit.edu: "Silicon on Sapphire" by CLASH
DrBob@cup.portal.com (Robert A Rethemeyer) (04/22/91)
Masuru Sugai writes... > [Scott Denham posting deleted] > [Mark Thompson posting deleted] I believe these gentlemen's difficulties are different than yours, and different from each other's. I sent them email, but have not received any response. > I've been frustrated with my A3090 (C= 150MB QIC) I picked up yesterday. I thought it was called A3070. Is A3090 something new? > I gave up MWtape and went to BTN. BTN seems quite useful, especially its > tapemon tool is wonderful as it shows what's going on in tape drives. > But there are several glitches. > > - I could store and restore files only when I set tape buffer to 512B long. > Buuut, it's slow (say, 15KB/sec) and consumes most of tape for block gaps ! > Nearly 80% of tape has used to just save 30MB. Many (maybe most) tape drives can use ONLY one size of tape buffer, usually 512 bytes. BTN allows you to specify different sizes for those drives that can vary it, but *not all drives can do this*. What do your drive docs say? You can still get good tape performance by increasing the number of blocks parameter. Try NB-128, which will give you 64KB data transfers (for BS-512). Tape performance is dependent on the total number of bytes transferred, not the buffer size. If you can't increase BS, then increase NB. The drive usually has no practical restriction on blocks per read/write. > - With buffer size over 1024B or more, TAR seems to write all data on tape. > Archiving speed is around 90KB/sec when I set buffer size to 64KB, > acceptable performance, judging from A3090 transfer rate (112.5KB/sec). > This is an option for a write-only mode, though. I can read, say, first > megs, but as soon as I hit upon a large file (a few hudred kilobytes), > TAR quits with Tapemon's "SELECTION TIMEOUT ERROR" message. I am better > off than they are, as I am free from lockup and guru SO FAR. SCSI SELECT TIMEOUT ERROR is printed when scsi.device returns the error code for this bus error. I'm not familiar with exactly what condition causes this error. But maybe this... if the drive and the handler have different ideas about what the buffer size is, it may confuse the adapter. The error happening on the read but not the write would seem to point to this. Try going back to BS-512 and NB-128. > I know what BTN stands for, but it is a decent implementation of tape > driver on standard Amiga configuration. It would be a BTA with a little > bit more of error handling... Any idea ? When I started on it a year ago, that's all that was available- NOTHING. I figured whatever I came up with had to be better than that :-) As for better error handling- I presume you mean error reporting? All I can do is report in english the error codes returned by the tape drive and scsi.device. I know of no means to determine the problem in any finer detail (at least for generic drives and adapters). > BTW, does anybody have working experience of TAR to exchange data with UNIX ? > I have no idea what is the most appropriate block size, as A3090 has nothing > technical on its booklet. Is there any preferred block size for each UNIX ? I know a couple people who have exchanged Unix TAR tapes with BTN, no problem. I don't think TAR will let you vary its data blocks on the tape, so as long as the medium is compatible, the exchange should work (but I could be wrong). Just curious- what does TapeMon report for the drive manufacturer/model? > -- Masaru Sugai =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bob Rethemeyer // "My Sneaker-Phone keeps kicking my DrBob@cup.portal.com -or- // Football-Phone off the hook." ..!sun!portal!cup.portal.com!DrBob // - Jay Leno
stephane@grasp1.univ-lyon1.fr (Stephane Guillard) (04/22/91)
In article <5692@media-lab.media.mit.edu.MEDIA.MIT.EDU> masaru@media-lab.media.mit.edu (Masaru Sugai) writes: >In article <61897@masscomp.westford.ccur.com> mark@calvin.westford.ccur.com (Mark Thompson) writes: >>In article <1991Apr13.014520.13657@sugar.hackercorp.com> ssd@sugar.hackercorp.com (Scott Denham) writes: >>>Does anyone recognize these symptoms? >>> I'm running BTNTape 2.0 on an A2000 / A2090A to a Cipher 540 1/4" tape >>>drive. I can get TAR to read from the drive, but after some >>>(variable) number of blocks are read, the system locks up solid. >> [...] >Encouraged with this success, I then tried TAR+MWtape from fish #440s, and >it ruined my Saturday night! I had to check several FTP sites, CIS, and BIX >to get ARP mount command which MWtape requires, but no avail. > >I gave up MWtape and went to BTN. BTN seems quite useful, especially its >tapemon tool is wonderful as it shows what's going on in tape drives. >[...] >-- Masaru Sugai MWTape does not actually NEED ARP Mount to work properly if you own a C compiler : you can hardwire all the STARTUP params in the source code ; just use the defaults (SCSI ID 4 for the 3090 ; bs 512, etc...) and you'll be able to read'n'write Unix-compatible ATR tapes (150mb) perfectly (I do it each day). If you're interested in the : A - directly usable binary B - modified source then email me and I'll forward this to you. -- \\\ Only Amiga | Stephane GUILLARD - GRASP INSA Lyon FRANCE \\\ makes it | Tel: +33 72438383 poste 5546 \\\/// possible! | eMail at : stephane@grasp1.univ-lyon1.fr \XX/
ssd@sugar.hackercorp.com (Scott Denham) (04/23/91)
In article <5692@media-lab.media.mit.edu.MEDIA.MIT.EDU>, masaru@media-lab.media.mit.edu.MEDIA.MIT.EDU (Masaru Sugai) writes: > > BTW, does anybody have working experience of TAR to exchange data with UNIX ? > I have no idea what is the most appropriate block size, as A3090 has nothing > technical on its booklet. Is there any preferred block size for each UNIX ? > Haven't tried going the other way, but I *can* read tapes created on my Unix (ICM-3216) system without problems (other than the aforementioned lockups) using Amiga tar and BTNTape 2.0. Interestingly if I slow the operations down (for example "type tape: opt h"), the lockups don't happen and I can see the ASCII portions of the Unix files (e.g. man pages) dumped correctly. My problems all seem to be timing related :( Scott Denham ssd@sugar.hackercorp.com
ssd@sugar.hackercorp.com (Scott Denham) (04/23/91)
In article <41542@cup.portal.com>, DrBob@cup.portal.com (Robert A Rethemeyer) writes: > > [Scott Denham posting deleted] > > [Mark Thompson posting deleted] > > I believe these gentlemen's difficulties are different than yours, and > different from each other's. I sent them email, but have not received > any response. > I did get your message, Bob, and thanks very much! I'm not yet convinced that the picture for the A2090A is quite as hopeless as you paint, but you may be right. It's certainly an orphaned, unsupported product! I'd take your advice and do the GVP trade-in, but right now I depend on the A2090a to support my ST-506 drive and both an new drive and new controller are not in the budget right now. Incidentally, you asked whether I was running into the SCSI hard drive conflict problem with the 2090a; the answer is no - first I no longer have a (working) SCSI drive on the system (THANKS, Seagate!) and secondly the lock up occurs even when doing an operation that does not involve the A2090A other than as a tape controller, for example "tar -tvf tape:". Anyway, thanks for your response, and particular thanks for your efforts on BTNTape! Scott Denham ssd@sugar.hackercorp.com ps. return mail bounced repeatedly, thus the followup....
masaru@media-lab.media.mit.edu.MEDIA.MIT.EDU (Masaru Sugai) (04/23/91)
First of all, I appologize for my misunderstanding. I got an e-mail from Bob
(author of BTNtape), and he suggested me to use BS-512 as most of tape drives
have a fixed length buffer size of such, and NB as many as possible. Here go
my quick results of TAR + BTN2.0 performance.
Configuration
A3000/16 w/ 2MB CHIP, 4MB FAST built-in SCSI
A3070 150MB tape drive (C=)
mountlist Startup PARAMETER BS-512, OV-1, UN-4
productivity w/ 4 color
Full dump
----------------------------------------------------------------------------
(1) Dumping 27MB of WORK: partition (NB-128) 12:10
cd work:
tar cvf tape: .
(2) Listing of archived tape (1) (NB-128) 7:50
tar tvf tape:
NOTE: I have no disk space to restore them :(
---------------------------------------------------------------------------
NB variation
--------------------------------------------------------------------------
Dumping and restoring 3.9 MB files
tar cvf tape: . tar xvf tape:
(5) NB-128 2:18 0:50
(6) NB-256 1:32 not measured
(7) NB-1024 1:00 not measured
(8) NB-2048 1:00 0:47
--------------------------------------------------------------------------
Test conditions are really ad hoc, but it should delineate real characteristic
of NB factor over total performance. The break even point seems to lay between
256 and 1024, but I haven't checked in-between setting as of yet.
[BTW, I found several discrenpancies in tape.doc documentation. It might be
peculiar to 2.0, I guess.
- "type > tape: tape.doc" works fine, but WB "can't open tape:" for
"type tape:". Strange to say, WB prefers "more tape:"
- "assign tape: removed" should be "assign tape: dismount" in WB2.0.
There is a dreadful notice in AmigaDOS reference though.
]
According to the '3070 tape drive installation guide', data transfer rate
of A3070 is 112.5KB/sec. (8) gives approximately 65(81)KB/sec, about 58(72)%
of maximum transfer rate. I have no idea what to interpret these numbers,
but an article "TAPE BACKUPS" in Nov 1990 issue of MacWorld carries a
benchmark tests, and typical 150MB stand at over 75KB/sec for file-by-file
backup. With this price range, A3070 could be a better buy if C= would
support tape driver for non-UNIX Amigas :)
I'm still wondering how much I can actually store on a single cartrige.
Any suggestions and comparisons (especially tape drives in other platform)
are very welcome.
As for data exchange with UNIX, I was successful to read out archived files
from SUN4 this morning. We have HPs around at the lab, but they only gave
me fault light :(
In essence, BTN2.0+TAR works for A3000+A3070 at reasonable transfer rate as
long as NB is set to an appropriate number, and tapemon is a good accessory
just in case.
-- Masaru Sugai
PS
FYI: This is the initial message from 'tapemon'. Thanks Bob !
*** BTN-Tape Handler & Monitor ***
) Copyright 1990,1991 Robert Rethemeyer
TAPE: Proc 7C7BFF0 DevNode 7C2DA04
scsi.device Unit-4 LU-0
Drive: CALIPER CP150 A
Sequential Access
Last sense= FILEMARK, other=00,01
Use ^C to terminate TapeMon
-BTNTAPE V2.0 RAR-Mar 29 1991
TapeMon terminated
--
-- Masaru Sugai:Use disclaimer. CIS 72050,2141:NeXT + A3000 = money-eater
NEC Corporation:sugai@ccs.mt.nec.co.jp DORMANT:hardwired logic,machine language
MIT R.Affiliate:masaru@media-lab.media.mit.edu: "Silicon on Sapphire" by CLASHkent@swrinde.nde.swri.edu (Kent D. Polk) (04/24/91)
In article <5704@media-lab.media.mit.edu.MEDIA.MIT.EDU> masaru@media-lab.media.mit.edu (Masaru Sugai) writes: > > A3070 150MB tape drive (C=) > >As for data exchange with UNIX, I was successful to read out archived files >from SUN4 this morning. We have HPs around at the lab, but they only gave >me fault light :( Not sure about now, but HP's standard tape drives used to require pre-formatted DC-600 tape cartridges & weren't compatible with Sun's. Were these SCSI tape drives on the HP's? ===================================================================== Kent Polk - Southwest Research Institute - kent@swrinde.nde.swri.edu "Duct Tape is like the Force... It has a Light Side, a Dark Side, and it holds the Universe together" =====================================================================
mark@calvin..westford.ccur.com (Mark Thompson) (04/26/91)
In article <41542@cup.portal.com> DrBob@cup.portal.com (Robert A Rethemeyer) writes: >> [Mark Thompson posting deleted] > >I believe these gentlemen's difficulties are different than yours, and >different from each other's. I sent them email, but have not received >any response. Bob, I tried responding via DrBob@cup.portal.com and sun!portal!cup.portal.com!DrBob but both bounced back in my face. Seems my mailer gives me about as much trouble as BTN :-). Here is what I wrote: Thanks for the extremely informative letter. I had been avoiding the giga-bytes of bandwidth on the "reselection" bug because I have been successfully using multiple hard drives with the 2091 for over a year (Quantum Prodrives and a 280M Maxtor). I guess it has finally reared its ugly head on the Archive Viper 2525. I'll have to see what I can do about disabeling reselection tonight. I'll let ya know what happens. Thanks again for the info, and more importantly the much needed tape driver. Anyway, the Archive Viper 2525 docs I have say you can change the disconnect size but make no mention of being able to disable it. I have not been able to play around with it much since my machine has been tied up rendering a 3D animation 24 hours a day for the past 4 weeks (over 1000 24bit frames hence the need for tape backup). After Saturday it will be done and I can get back to it but I don't expect much unless Tim Jones at Maynard Electronics, possibly someone from Commodore, or you can shed some additional light on this matter. >I know a couple people who have exchanged Unix TAR tapes with BTN, no problem. When it didn't lock up on me, it did this just fine. %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~% % ` ' Mark Thompson CONCURRENT COMPUTER % % --==* RADIANT *==-- mark@westford.ccur.com Principal Graphics % % ' Image ` ...!uunet!masscomp!mark Hardware Architect % % Productions (508)392-2480 (603)424-1829 & General Nuisance % % % ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jesup@cbmvax.commodore.com (Randell Jesup) (04/27/91)
In article <41542@cup.portal.com> DrBob@cup.portal.com (Robert A Rethemeyer) writes: >SCSI SELECT TIMEOUT ERROR is printed when scsi.device returns the >error code for this bus error. I'm not familiar with exactly what condition >causes this error. When the A3000 was designed, the clock rate to the WD chip was doubled, but current released versions of the kickstart (scsi.device) don't have changed timeout values, which depend on clock frequency. The next release should have proper values (note that the only other unit I've ever seen a timeout with was a Seagate ST125N). Registered developers already have betas with the modification. If you obtain the BattMem program (on comp.sources.amiga.*) you can set the "seagate" bit, which increases select timeouts to ~1 second, among other things. That should hide your timeout problem for the time being. WITH standard_disclaimer; USE standard_disclaimer; -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
masaru@media-lab.media.mit.edu.MEDIA.MIT.EDU (Masaru Sugai) (04/30/91)
In article <5704@media-lab.media.mit.edu.MEDIA.MIT.EDU> masaru@media-lab.media.mit.edu (Masaru Sugai) writes: >I'm still wondering how much I can actually store on a single cartrige. >Any suggestions and comparisons (especially tape drives in other platform) >are very welcome. This is a silly question for hardware wizards, but I would like to know how my QIC tape drive stores data on tape. Today I bought a 3M DC6150, and tried full backup again but the result was similar. Tape was wound to near the end after dumping 27MB in 440 sec. I noticed there were changes in the motor sound, and I stopped tar 150 sec after invocation to find out the tape was almost 'wound up'. I went through A3070 installation guide and made a simple calculation. DC6150 media volume 7,440 inches (620 ft) Data density 10,000 BPI | realistic backup time 9.3 MB | 2 min 30 sec Number of tracks 18 | 167.4 MB | 45 min My calculation seems to be reasonable as 27MB backup amounts to one and half r(w)ound trip. This is my last concern on A3070 which has been holding me off 100% confidence over two weeks. Any info is appreciated. PS I placed my order on SCSI2/1 and custom 50F cable so as to hook it up to NeXT and DECstation in our office. I might post my results... -- -- Masaru Sugai:Use disclaimer. CIS 72050,2141:NeXT + A3000 = money-eater NEC Corporation:sugai@ccs.mt.nec.co.jp DORMANT:hardwired logic,machine language MIT R.Affiliate:masaru@media-lab.media.mit.edu: "Silicon on Sapphire" by CLASH
billsey@nesbbx.UUCP (Bill Seymour) (05/01/91)
In article <5692@media-lab.media.mit.edu.MEDIA.MIT.EDU>, Masaru Sugai writes:
:
: I've been frustrated with my A3090 (C= 150MB QIC) I picked up yesterday.
: I hooked it up to A3000/16, and was easy to take a full backup of WORK:
: using BRU w/o any problems. All I had to do were moving tape: entry
: to the top of BRUtab file, then "bru -c" at the root directory. That's it.
:
: Encouraged with this success, I then tried TAR+MWtape from fish #440s, and
: it ruined my Saturday night! I had to check several FTP sites, CIS, and BIX
: to get ARP mount command which MWtape requires, but no avail.
:
: I gave up MWtape and went to BTN. BTN seems quite useful, especially its
: tapemon tool is wonderful as it shows what's going on in tape drives.
: But there are several glitches.
:
: - I could store and restore files only when I set tape buffer to 512B long.
: Buuut, it's slow (say, 15KB/sec) and consumes most of tape for block gaps!
: Nearly 80% of tape has used to just save 30MB.
:
: - With buffer size over 1024B or more, TAR seems to write all data on tape.
: Archiving speed is around 90KB/sec when I set buffer size to 64KB,
: acceptable performance, judging from A3090 transfer rate (112.5KB/sec).
: This is an option for a write-only mode, though. I can read, say, first
: megs, but as soon as I hit upon a large file (a few hudred kilobytes),
: TAR quits with Tapemon's "SELECTION TIMEOUT ERROR" message. I am better
: off than they are, as I am free from lockup and guru SO FAR.
:
: I know what BTN stands for, but it is a decent implementation of tape
: driver on standard Amiga configuration. It would be a BTA with a little
: bit more of error handling... Any idea ?
Here's my mountlist entry for BTNtape: on my 3000:
BTNTAPE:
Handler = l:btntape-handler
Priority = 5
Mount = 1
Stacksize = 4000
GlobVec = -1
Startup = "scsi.device/UN-3/BS-512/NB-128/BT-1"
#
This gives me reasonable performance, even though the numbers were
just guesses originally. My guess is you have something wrong on the Amiga
side with reselection. The tape streams constantly on large files and only
does a start/stop when dealing with many small files. I'm using TAR (The one
that is 33860 bytes in length and has the patch to allow for UNIX compatibility.)
: -- Masaru Sugai
:
: -- Masaru Sugai:Use disclaimer. CIS 72050,2141:NeXT + A3000 = money-eater
: NEC Corporation:sugai@ccs.mt.nec.co.jp DORMANT:hardwired logic,machine language
: MIT R.Affiliate:masaru@media-lab.media.mit.edu: "Silicon on Sapphire" by CLASH
-Bill Seymour nesbbx!billsey@agora.uucp or nesbbx!billsey@agora.rain.com
***** American People/Link Amiga Zone Hardware Specialist NES*BILL *****
Bejed, Inc. NES, Inc. NAG BBS NES BBX BBS Home Sometimes
(503)281-8153 (503)246-9311 (503)656-7393 (503)640-9337 (503) 640-0842