Mariusz@fbits.ttank.com (Mariusz Stanczak) (02/18/91)
Having recently accuired a tape backup unit (thanks Vince), I have the following quiestions: - what is the size of one "segment" (23MB/6/254 not integer size)? - has anyone created a standalone boot floppy with a configuration that would permit the use of the tape unit? What would that entail if I were to create one? - even with large blocking (256KB is the largest I could enter to `gtar') the unit does not seem to "stream" for long... it's runs more like a saw, forth and back. Is that it's "beauty"? This be- havior makes it VERY slow (though I appreciate having the ability to "compress"-backup the whole 44MB on one cart :-)). Any work-arounds (`dbuf' does help some, but not enough)? Thanks to all, -Mariusz -- INET: Mariusz@fbits.ttank.com CIS : 71601.2430@compuserve.com UUCP: ..!uunet!zardoz!ttank!fbits!Mariusz
jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (02/19/91)
In article <72@fbits.ttank.com> Mariusz@fbits.ttank.com (Mariusz Stanczak) writes: >Having recently accuired a tape backup unit (thanks Vince), >I have the following quiestions: > > - has anyone created a standalone boot floppy with > a configuration that would permit the use of the > tape unit? What would that entail if I were to > create one? Look on OSU - Lenny posted something like this, using the .o's for the kernel and the tp driver, you made a bootable floppy. > - even with large blocking (256KB is the largest > I could enter to `gtar') the unit does not seem > to "stream" for long... it's runs more like a saw, > forth and back. Is that it's "beauty"? This be- > havior makes it VERY slow (though I appreciate > having the ability to "compress"-backup the whole > 44MB on one cart :-)). Any work-arounds (`dbuf' > does help some, but not enough)? I was working on this for a while, but gave up in disgust. There was *no* documentation on the driver interface! Even with a little help from some friends, it was still pretty ugly. There was no *distributed* tp.h file, and the man page for qt(7) is positively not what we have - there were no working QIC-02 boards for the general public. What probably has to be done is to make a diffent kind of dbuf (maybe tbuf?) that stores huge data chunks. If you can push enough data at the tape, you can get about a 6.5 second stream, the most I ever saw :-( If anyone ever managed to get it to really stream, I'd be delighted to hear how!! j -- Jeffrey L. Bromberger System Operator---City College of New York---Science Computing Facility jeffrey@sci.ccny.cuny.edu jeffrey@ccnysci.BITNET Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey
dnichols@ceilidh.beartrack.com (DoN Nichols) (02/19/91)
In article <72@fbits.ttank.com> Mariusz@fbits.ttank.com (Mariusz Stanczak) writes: >Having recently accuired a tape backup unit (thanks Vince), >I have the following quiestions: > [ ... ] > - has anyone created a standalone boot floppy with > a configuration that would permit the use of the > tape unit? What would that entail if I were to > create one? Yes, it has been done. By Lenny Tropiano. See pub/att7300/fpunix_tp.sh.Z on osu-cis. > - even with large blocking (256KB is the largest > I could enter to `gtar') the unit does not seem > to "stream" for long... it's runs more like a saw, > forth and back. Is that it's "beauty"? This be- Don't you appreciate having a head polishing machine? :-) I wish that there would be some progress on getting a scsi interface and driver so I could hang the adaptec/archive combo on the system (or even better a (now what IS the name of that 2.3GB drive that I can't afford?). > havior makes it VERY slow (though I appreciate > having the ability to "compress"-backup the whole > 44MB on one cart :-)). Any work-arounds (`dbuf' > does help some, but not enough)? > What is happening is that it writes the block rather quickly, but the next block is not yet ready. The tape drive stops, backs up far enough, and when the next block comes through, it gets a running start. This happens even without the compress mode turned on, but of course, is even worse with compress mode. I'm used to this kind of behavior from my old Cipher f880 drive. It is quite reasonable if you can feed it fast enough to keep it streaming, but most backup archivers couldn't, at least on my old v7 system. Sorry that I don't have more encouraging news. DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
Mariusz@fbits.ttank.com (Mariusz Stanczak) (02/19/91)
In article <1991Feb18.162005.15219@sci.ccny.cuny.edu> jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes: [description of "saw tape" deleted] >I was working on this for a while, but gave up in disgust. There was >*no* documentation on the driver interface! Even with a little help >from some friends, it was still pretty ugly. There was no >*distributed* tp.h file, and the man page for qt(7) is positively not >what we have - there were no working QIC-02 boards for the general >public. I was looking for that tp.h driver as well... what an "oversight" on AT&T side ;-( Does anyone have more on the faith of that piece of information? >What probably has to be done is to make a diffent kind of dbuf (maybe >tbuf?) that stores huge data chunks. If you can push enough >data at the tape, you can get about a 6.5 second stream [...] The largest -T I tried so far was 0.5MB, but even with `dbuf''s double buffering `gtar' (and for that matter all other processes) seem to be prevented from working when the tape does its "seeks" (the MeterMaid's kernel line goes 100%), so this whole idea turns kind of flat (the point would be to keep the thing streaming. Then the resource use by the dri- ver seems very low). All these handicaps seem to go together with the rest of the implementation (23MB out of a 60MB media?!?), and the culprit looks to be the I/F board (or is there more to it?). Anyways, looks like another exciting (and very marketable ;-)) project for the 3B1 wizards-at- -large, armed with the Technical-Docs-and-sources, and patience of us, the-buyers-to-be. Are you listening? Can this thing be made to work right? BTW, How is the reliability of the device as it is, i.e. working VERY hard? All in all, I'll take it any day over floppies, if it doesn't break too often. -Mariusz -- INET: Mariusz@fbits.ttank.com CIS : 71601.2430@compuserve.com UUCP: ..!uunet!zardoz!ttank!fbits!Mariusz
dnichols@ceilidh.beartrack.com (DoN Nichols) (02/20/91)
In article <73@fbits.ttank.com> Mariusz@fbits.ttank.com (Mariusz Stanczak) writes: >The largest -T I tried so far was 0.5MB, but even with `dbuf''s double >buffering `gtar' (and for that matter all other processes) seem to be >prevented from working when the tape does its "seeks" (the MeterMaid's >kernel line goes 100%), so this whole idea turns kind of flat (the point >would be to keep the thing streaming. Then the resource use by the dri- >ver seems very low). All these handicaps seem to go together with the >rest of the implementation (23MB out of a 60MB media?!?), and the culprit >looks to be the I/F board (or is there more to it?). Anyways, looks like >another exciting (and very marketable ;-)) project for the 3B1 wizards-at- >-large, armed with the Technical-Docs-and-sources, and patience of us, >the-buyers-to-be. Are you listening? Can this thing be made to work >right? BTW, How is the reliability of the device as it is, i.e. working >VERY hard? All in all, I'll take it any day over floppies, if it doesn't >break too often. The capacity problem is caused by the choice of a floppy-tape interface drive. This drive requires the pre-formatted tapes, and second, uses only six tracks on the tape. The Archive drive which I use with teacat (tek 6130), is using nine tracks. (I forget which is the interface spec, and which is the format spec, I think one is QIC-24 and the other QIC-36). This is driven by a scsi interface through a Adaptec controller. The drive also DOES NOT require a pre-formatted tape, nor does it enforce a retension pass when the tape is loaded. (The retension pass is built into the firmware of the tape drive. Try disconnecting it from the computer, powering it up, and putting in a tape. It WILL retension.) Probably good idea to use a write-protected tape if there's anything on it, though I don't think that the drive will try to write while disconnected from the system. First, we want to use such a drive, second, if we don't make a scsi interface and driver for the drive, we want to make an INTELLIGENT controller to live in the slot. It should have a 6809 or better for intelligence, and a buffer memory of 512k or so. (Hmm, if we don't use fifo's for the buffer, then maybe we need to see that 6809 and raise it to a 68008. :-). The controller MUST be INTELLIGENT, so it can be transferring from its own memory to the tape drive while the system is building up the next buffer full Ideally, we want to have two full buffers, say two 256k buffers, and independent hardware transferring the first buffer to tape, while the system loads the second buffer. This would give the system a chance to keep the drive streaming. (Even if we can't keep it streaming, the Archive drive is much better about stopping the tape quickly, and re-starting it after re-positioning for the IRG.) Does anybody out there have a source for an extender card for the 3b1? I am reluctant to attempt any interface board design when I can't probe the board unless the system is stripped nude, and the backplane board is stressed by bending the board-under-test away from the cpu board. (No! I haven't tried this, and don't intend to!) Sounds like a good project, but like most others, the available time for the project is the limiting factor. (Maybe when I retire :-) Good Luck All DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
Mariusz@fbits.ttank.com (Mariusz Stanczak) (02/25/91)
In article <1991Feb20.030951.3963@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: [...] [Archive] > First, we want to use such a drive, second, if we don't make a scsi >interface and driver for the drive, we want to make an INTELLIGENT >controller to live in the slot. It should have a 6809 or better for Having a choice between puting effort into "floppy tape" improvments, and getting the SCSI card (hey, who's working on this?) out, my vote (my recent tape package aquisition notwithstanding) goes to the SCSI project. If properly implemented it'd offer flexibility never before available to the Upc, and would extend the systems usefull life by a great number of years. Having had a minor part in SCSI I/F undertaking for a different machine, I'm in a posesion of assembler source for such a driver that I'm willing to share with the people involved in getting such I/F for the 3B1. There was a custom hardware instead of the usual NCR chip, and it's written not in the funky USG syntax assembler (not to mention a different OS), but large parts of the code could be rescued. BTW, my worries concerning the way "Floppy tape" works, and the potential reliability problems may have been premature... I examined the head, and to my surprise, the thing is absolutely flawless (well polished too ;-))! Nice, for a previously owned piece of hardware. I'd like to second the recent posting about Computer Horizons... that's where I got the subsystem, and I'm very satified with how things went... from start to finish. For what it's worth, -Mariusz -- INET: Mariusz@fbits.ttank.com CIS : 71601.2430@compuserve.com UUCP: ..!uunet!zardoz!ttank!fbits!Mariusz