nickerso@bdofed.UUCP (b) (06/27/89)
Hello World! Hi. We're having trouble with backups on a 9track. We have two 3b2s (a 622 and a 700). We have the tape unit on the 700 and ethernet between the two. We have /dev mounted under RFS on the 622. The problem is that the backups are taking FOREVER! (well, almost :-) The backup of the 700 machine uses 1 1/2 2400 foot tapes (at 6250) and takes over 2 hours! The 622 requires more that 3 tapes (needless to say, it takes several hours) and we have not been able to determine exactly how long this is taking as we do not have staff here around the clock and it usually has to wait 'til the next day to change tapes. Has anyone else had any experience with the 9track on a 3b2? Our contacts at AT&T say that the throughput should be much higher. It seems that the drive is stopping and starting as it writes (an indication that the buffering can't keep up with the drive???) which means it has to back up so that it can get the tape to the right speed at the right time. Not exactly a time saver! Please, any comments or suggestions would be welcome. Send me email or phone or whatever. Thanks Bill nickerso@bdofed Etobicoke Board of Education 1 Civic Centre Ct, Etobicoke, Ontario (416)394-7182
gentry@kcdev.UUCP (Art Gentry) (06/27/89)
In article <125@bdofed.UUCP>, nickerso@bdofed.UUCP (b) writes: > > [problem description/layout deleted] > > Has anyone else had any experience with the 9track on a 3b2? Our > contacts at AT&T say that the throughput should be much higher. It seems > that the drive is stopping and starting as it writes (an indication that > the buffering can't keep up with the drive???) which means it has to back up > so that it can get the tape to the right speed at the right time. Not exactly > a time saver! > The AT&T 9track drive is really a Hewlett Packard 7980 drive that AT&T has OEMed. I have a couple on an HP9000/850. This is a streaming tape drive, but you need to have the right bit set in the driver to put it into streaming mode. Sounds like you have one of two possible problems: 1) the bit is not set and the drive is running in start/stop mode or 2) your backup utility is not feeding data to the drive fast enough to keep it streaming. The drive will only stream as long as there is data in the buffer to feed it. If it runs out of data, the tape will stop, wait for the buffer to hit x percentage full and then backup/re-stream to dump that data. If the buffer empties again, it starts the process all over again. -- | R. Arthur Gentry AT&T Communications Kansas City, MO 64106 | | Email: killer!kcdev!gentry ATTMail: attmail!kc4rtm!gentry | | The UNIX BBS: 816-221-0475 The Bedroom BBS: 816-637-4183 | | $include {std_disclaimer.h} "I will make a quess" - Spock - STIV |
rwa@aurora (Ross Alexander) (06/27/89)
In <125@bdofed.UUCP>, Bill Nickerso[n?] observes that tape backups
between two 3b2's (600,700) on an ethernet
... "are taking FOREVER! (well, almost :-)".
One question: are you running Starlan or TCP/IP over your 10BASE5
transport layer? If TCP/IP, which version? We have 3.0, and I would
say that if you have a 2.x version, you are experiencing normal RFS
throughput. About Starlan speeds I know nothing. TCP version 3.0
is a noticable improvement over 2.x from our measurements.
If you are running TCP, about the only thing you can do is to increase
the number of large blocks in the streams buffer pool ( have a look in
etc/masterd/kernel; you want to increase the values assigned to
NBLK{4096,2048,1024} to about say four times as large as the default
values ). I would expect this to be true of Starlan as well, without
ever having used it :-).
The only other thing I can suggest is to have a look at the lamps
on your transcievers: if the red collision lamps are flashing at all
frequently, and you have only 2 machines on your net, then something
is pretty wrong at the MAC layer. (MAC == media access control).
In closing, let me say that RFS throughputs have been pretty
disappointing in our shop - typically, RFS from 3b2/600 <---> 3b2/600
over 10base5 (thick ethernet) transport has been about 6 to 8 times
_slower_ than NFS transport between random small Sun 3's and
microVaxen on the same backbone. RFS seems to pay a heavy price for
maintaining all that state information and local-filesystem-semantics.
Of course, there's times when that's really what you want :-) - as
anyone who's tried to NFS-access a tape drive knows. [For the
uninitiated, that trick can't be done by NFS - he only does _files_,
not remote devices.] But that isn't the main reason to have a
distributed filesystem, IMHO.
Rosslyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (06/28/89)
nickerso@bdofed.UUCP (b) writes: > Has anyone else had any experience with the 9track on a 3b2? Our >contacts at AT&T say that the throughput should be much higher. It seems >that the drive is stopping and starting as it writes (an indication that >the buffering can't keep up with the drive???) which means it has to back up >so that it can get the tape to the right speed at the right time. Not exactly >a time saver! Our current config is a 3b2/600 tied to a 3b4000 (which has the 9track). We RFS mount /dev/{rmt,rSA} from the 4000 onto the 600. I checked with the operators, and they indicate a full backup of the 600 (about 500MB) is taking about 16 hours. The problems here are manyfold. The prime culprit is the 9track, and its associated drivers. Physical throughput to the drive is bad at the best of times, and I'm convinced the driver is doing nothing to help out. I've run the same drive off a Sun 3/280 and made the thing STREAM at 6250 during backups. If you can't get the drive out of washtub mode ... RFS is also no screaming hell. A lot of the problem in our case is the painfully slow ethernet interface on the 3b4000. We're lucky to get 40K/sec through the wire doing ftp's, let alone RFS traffic. Savecpio is not know for writing huge blocks, either. I'm not sure of the size it uses, but watching the tape wobble on the drive I would guess no larger than 10K/block. I'll check the source and see what the story is here. Something you might want to try would be to dd 100 meg from the raw filesystem over the wire to the tape drive. Time how long it takes, the run it again with output to /dev/null on the remote. This should give you an idea of how much of a hit you're taking from the tape. > Please, any comments or suggestions would be welcome. Send me email >or phone or whatever. A comment: I guess you haven't seen what happens when you take a tape error towards the end of your dump set :-) Ever think about porting Berkeley dump? We have ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,ncc}!atha!lyndon || lyndon@cs.AthabascaU.CA If everyone quit smoking, drinking, and buying gas, the nation would probably go bankrupt.
wolfordj@ihlpy.ATT.COM (452is-Wolford) (06/28/89)
From article <125@bdofed.UUCP>, by nickerso@bdofed.UUCP (b): > Hello World! > Hi. We're having trouble with backups on a 9track. We have two > 3b2s (a 622 and a 700). We have the tape unit on the 700 and ethernet > between the two. We have /dev mounted under RFS on the 622. The problem > is that the backups are taking FOREVER! (well, almost :-) The backup of ... ... > Has anyone else had any experience with the 9track on a 3b2? Our > contacts at AT&T say that the throughput should be much higher. It seems > that the drive is stopping and starting as it writes (an indication that > the buffering can't keep up with the drive???) which means it has to back up > so that it can get the tape to the right speed at the right time. Not exactly > a time saver! > > Bill > > nickerso@bdofed > Etobicoke Board of Education > 1 Civic Centre Ct, Etobicoke, Ontario > (416)394-7182 YEP, think of what you are doing. Taking the information off the of the disk (ie 1 - going through the disk controller, 1A - to the SCSI controller 2 - to the 3B2, 3 - to the networking card 4 - through the network 5 - to the networking card 6 - to the 3B2 7 - to the SCSI controller 8 - and to the 9 track controller Steps 3 - 6 are removed from the process if you don't have the take mounted over a lan. Think about it. Have questions send mail and I will give a more detailed explaination of "why" this occurs and that little you do could make the tape drive on the RFS'ed machine to stream. Jeff Wolford att!iwsag!jww att!ihlpy!wolfordj harvard-+ | ucbvax--+---- att --+ iwsag!jww | decvax--+
les@chinet.chi.il.us (Leslie Mikesell) (06/28/89)
In article <125@bdofed.UUCP> nickerso@bdofed.UUCP (b) writes: >Hello World! > Hi. We're having trouble with backups on a 9track. We have two >3b2s (a 622 and a 700). We have the tape unit on the 700 and ethernet >between the two. We have /dev mounted under RFS on the 622. The problem >is that the backups are taking FOREVER! (well, almost :-) The backup of >the 700 machine uses 1 1/2 2400 foot tapes (at 6250) and takes over 2 >hours! I've tried this with 3b2/400's with 1M starlan and cartridge tapes and found that it works better to mount the remote disk into the machine with the tape drive instead of accessing the tape device remotely. This does require root access to the remote files (map 0:0) but that is not a problem here. An alternate possibility without special programming would be to create a FIFO in a common directory to pass the data (Has anyone tried this?). For a more dramatic improvement you need a method of double-buffering on the machine that has the tape drive so the network and tape io can overlap. Also a program that would make a TLI level link directly between the machines would help by eliminating the RFS overhead. Les Mikesell