Dyslexia sucks... sorry, if it was not obvious, please globally substitute s:STOP/STOP:START/STOP: ᐧ On Sun, Dec 31, 2023 at 2:30 PM Clement T Cole via groups.io wrote: > Small PS below... > > On Sat, Dec 30, 2023 at 9:27 PM Clement T Cole via groups.io ccc.com@groups.io> wrote: > >> >> I did not say that or imply it. But variable vs. fixed blocking has >> implications on both mechanical requirements and ends up being reflected in >> how the sw handles it. Traditional 9-track allows you to mix record sizes >> on each tape. Streamer formats don’t traditionally allow that because they >> restrict / remove inter record gaps in the same manner 9-track supports. >> This increases capacity of the tape (less waste). >> > > In my explanation, I may have been a tad confusing. When I say fixed > records -- I mean on-tape fixed records, what the QIC-24/120/150 standard > refers to as: "*A group of consecutive bits comprising of a preamble, > data block marker, a single data block, block address and CRC and postamble*" > [the standard previous defines a data black os 512 consecutive bytes] --* > i.e*., if you put an o'scope on the tape head and looked at the bit > stream (see page 16 of QIC-120 Rev F - Section 5 "Recorded Block" for a > picture of this format -- note is can only address 2^20 blocks per track, > but it supports addressing to 256 tracks -- with 15 tracks of QIC-120 that > means 15728640 unique 512-byte blocks). > > STOP/STOP does something similar but encodes the LRECL used [I don't have > the ANSI tape standard handy - but I remember seeing a wonderful picture of > all this from said documents when I first was educated about tapes in my > old IBM days ~50 years ago]. After each record, STOP/STOP needs an > "Inter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down time > before continuing the bit stream of the next data block. The IRC distance > is something like 5-10 mm [which is a great deal compared to the size of a > bit when using GCR encoding (which is what 6250 BPI and QIC both use). > These gaps take space (capacity) from the tape, so people tend to write > with larger blocking factors [UNIX traditionally uses 10240 bytes- other > systems use other values - as I said, I believe the standard says the max > is 64K bytes). > > Since streamers (like QIC tape) are supposed to be continuous, the QIC > inter-records gaps resemble fixed disk records and can be extremely small. > Remember, each bit is measured in micrometers -- about *2 micrometers*, > IIRC for QIC and around 10 for ½" formats -- again, and I would need to > check the ANSI spec, which is not handy. But this is a huge space savings > even with a smallish block (512) -- again - this was lifted from disk > technology of the day which had often standardized on 512 8-bit byte blocks > by then. > > BTW: this is again why I suspect a TK25 tape is not going to be able to > read on QIC-24/120/150 drive if, indeed, page 1-5 of the TK25 user manual > says it supports four different block sizes [1K/2K/4K/8K]. First, the > data block format would have to be variable to 4 sizes, and second, the > preamble would need to encode and write what size block to expect on > read. Unfortunately, that document does not say much more about the > physical tape format other than it can use cartridges "similar to ANSI > Standard X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11 > tracks, 8000 bpi" recording density (/w 10000 flux reversals per in), using > a "single track NRZI dat in a serpentine pattern, with 4-5 run length > limited code similar to GCR." > > That said, most modern SW will allow you to *write* different size record > sizes (LRECL) in the user software, but the QIC drives and I believe things > like DAT and Exabyte will only write 512-byte blocks, so somewhere between > your user program and tape itself, the write will be broken into N 512 byte > blocks and then pad (with null is typical) the last block to 512 bytes. > My memory is the QIC standard is silent on where that is done, but I > suspect it's done in the controller and the driver is forced to send it > 512-byte blocks. > > So, while you may define blocks of different sizes, unlike ½", it will > always be written as 512-byte blocks. > > That said, using larger record sizes in your application SW can have huge > performance wins (which I mentioned in my first message) - *e.g.*, > keeping the drive streaming as more user data has been locked down in > memory for a DMA. But by the time the driver and the controller are > finished, it's fixed 512-byte blocks on the tape. > > > One other thing is WRT to QIC, which differs from other schemes. I > previously mentioned tape files - a feature of the ½" physical tape formats > not typically supported for QIC tapes. QIC has an interesting feature that > allows a block to be rewritten and replaced later on the tape (see the > section of spec/you user manual WRT for "rewritten" or "replacement > "blocks). I've forgotten all the details, but I seem to remember that > features were why multiple tape files were difficult to implement. > Someone who knows more about tapes may remember the details/be able to > explain -- I remember dealing with tape files was a PITA in QIC, and the > logic in a standard ½" tape driver could not be just cloned for the QIC > driver. > ᐧ > ᐧ > ᐧ > _._,_._,_ > ------------------------------ > Groups.io Links: > > You receive all messages sent to this group. > > View/Reply Online (#3631) | Reply > To Group > > | Reply To Sender > > | Mute This Topic | New Topic > > Your Subscription | Contact > Group Owner | Unsubscribe > [ > clemc@ccc.com] > _._,_._,_ > >