From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23498 invoked from network); 31 Dec 2023 21:39:31 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2023 21:39:31 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 935D443E6E; Mon, 1 Jan 2024 07:39:29 +1000 (AEST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by minnie.tuhs.org (Postfix) with ESMTPS id 38B3343E6C for ; Mon, 1 Jan 2024 07:39:23 +1000 (AEST) Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3bc09c568feso185359b6e.0 for ; Sun, 31 Dec 2023 13:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1704058762; x=1704663562; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gaOEOvEiECIi3Wy/P9JBklLgKyC0eeeN/qXOm+3www8=; b=Nom6WjNskAQPvvIJzadOE38yRXSpffn+DWv1rKzdW0AwBFPA73EHO+ZfnG6w1Cm2gk 3UmFD3bsHvkSrfAaLQShRS8o2W7bHs4tXHcevwg5tIsxuOtB+PUr3Yee1bibnSJ8q96k lpwrg7n9JVKe0pEmYqvUeujwIET9QGHcAA81E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704058762; x=1704663562; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gaOEOvEiECIi3Wy/P9JBklLgKyC0eeeN/qXOm+3www8=; b=H1h+0b7z/4eAxbIhfMhrQLJQ+uIXJaAEg6TS+wG186JlO0h5mQOYChDqkU8kjJvgRQ 64KDzMjoee5EGZrdQRY8gB9CJcsnA9t9M6ehLmoL+eIQc4tIvAi6DQrRcDmCa2C+SkZ8 QUYIypgp3JEkxQqmWR+pjoGkFo6cYViQao0kVJRl90uUgHFz+UIteODFfWQFqVawuXFc wMzvzFgIa/OOQq2yl2b4pRyT53OyXZeDPYB/LMgY+34X+5epFgDzxVOKXqMH17z1dzcM J1o4GgpxGKsLbkXDYflMu4hvnbO9mNSO6IJ84kgd3aYNaRXkqQx07ZFcoDfljdfUUkOb FWhw== X-Gm-Message-State: AOJu0YwZWsJsVWKP1+bCHcbUpQsw4d0XcaZ1TT24urbibABNnaa5DXkD Yr+u9fbGmURhyQxe3jzohQgerC8pHwLKR41SXtwAh1XK5wYM X-Google-Smtp-Source: AGHT+IEuhnhF4fLqLIFFOALtHVo3Hr08RK96Z9w87tlR/SzMcpaoCcDdDneLWgeH1uSj2m51ptCk1XjuyEwp+knQkGg= X-Received: by 2002:a05:6808:23c4:b0:3bb:c4d6:ca7c with SMTP id bq4-20020a05680823c400b003bbc4d6ca7cmr6806037oib.75.1704058762216; Sun, 31 Dec 2023 13:39:22 -0800 (PST) MIME-Version: 1.0 References: <656c72ae-2b6e-487c-a7bc-6e3a3896b49f@ieee.org> <53587999-897f-4b69-b476-b1c83dfaf816@ieee.org> <2cafc131-3e5d-4bf1-b0ee-537e3ed0f4cd@ieee.org> <75e8f333-98fc-45da-b109-fedaa9d78fdb@ieee.org> <17A5C98F69111E59.18542@groups.io> <17A601627CB0546A.18542@groups.io> In-Reply-To: <17A601627CB0546A.18542@groups.io> From: Clem Cole Date: Sun, 31 Dec 2023 16:38:45 -0500 Message-ID: To: simh@groups.io Content-Type: multipart/alternative; boundary="00000000000032d980060dd51931" Message-ID-Hash: GLTARZ4TWARQFLWHEUFGUNFSA4YS7T7I X-Message-ID-Hash: GLTARZ4TWARQFLWHEUFGUNFSA4YS7T7I X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Computer Old Farts Followers , "nw.johnson@ieee.org" X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: [simh] Old VAX/VMS Tapes List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000032d980060dd51931 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dyslexia sucks... sorry, if it was not obvious, please globally substitute s:STOP/STOP:START/STOP: =E1=90=A7 On Sun, Dec 31, 2023 at 2:30=E2=80=AFPM Clement T Cole via groups.io wrote: > Small PS below... > > On Sat, Dec 30, 2023 at 9:27=E2=80=AFPM 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 siz= es >> on each tape. Streamer formats don=E2=80=99t traditionally allow that b= ecause 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 postamb= le*" > [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 tha= t > 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 distanc= e > 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 =C2=BD" formats -- again, and I would need= to > check the ANSI spec, which is not handy. But this is a huge space saving= s > 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 bloc= ks > 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), usi= ng > 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 thin= gs > like DAT and Exabyte will only write 512-byte blocks, so somewhere betwee= n > your user program and tape itself, the write will be broken into N 512 by= te > 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 =C2=BD", it wi= ll > 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 =C2=BD" physical tape = formats > not typically supported for QIC tapes. QIC has an interesting feature th= at > 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 =C2=BD" tape driver could not be just cloned for the = QIC > driver. > =E1=90=A7 > =E1=90=A7 > =E1=90=A7 > _._,_._,_ > ------------------------------ > 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] > _._,_._,_ > > --00000000000032d980060dd51931 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dyslexia sucks... sorry, if it was not obvious, p= lease globally=C2=A0substitute=C2=A0 =C2=A0 s:STOP/STOP:START/STOP:
3D""=E1=90=A7
On Sun, Dec 31, 2023 at 2:30=E2=80=AFPM Clement T Cole via= groups.io <clemc=3Dccc.com@groups.io> wrote:
Small PS below...

On Sat, Dec 30, 2023 at = 9:27=E2=80=AFPM Clement T Cole via groups.io <clemc=3Dccc.com@groups.io> wrote:

I did not say that or imply it. =C2=A0 B= ut variable vs. fixed blocking has implications on both mechanical requirem= ents and ends up being reflected in how the sw handles it.=C2=A0 Traditiona= l 9-track allows you to mix record sizes on each tape.=C2=A0 Streamer forma= ts don=E2=80=99t traditionally allow that because they restrict / remove in= ter record gaps in the same manner 9-track supports.=C2=A0 This increases c= apacity of the tape (less waste).=C2=A0
<= div>
In my explanation, I may have been= a tad confusing.=C2=A0 =C2=A0When I say fixed records -- I mean on-tape fi= xed records, what the QIC-24/120/150 standard refers to as: "A g= roup of consecutive bits comprising of a preamble, data block marker, a sin= gle data block, block address and CRC and postamble" [the stan= dard 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= =C2=A0(see page 16 of QIC-120 Rev F - =C2=A0Section 5 "Recorded Block&= quot; 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 QI= C-120 that means 15728640 unique 512-byte blocks).

STOP/STOP does= something similar but encodes the LRECL used [I don't have the ANSI ta= pe standard handy - but I remember seeing a wonderful picture of all this f= rom said documents when I first was educated about tapes in my old IBM days= ~50 years ago].=C2=A0 =C2=A0After each record, STOP/STOP needs an "In= ter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down t= ime before continuing the bit stream of the next data block.=C2=A0 The IRC = distance is something like 5-10 mm [which is a great deal compared to the s= ize of a bit when using GCR encoding (which is what 6250 BPI and QIC both u= se). These gaps take space (capacity) from the tape, so people tend to writ= e with larger blocking factors [UNIX traditionally uses 10240 bytes-=C2=A0o= ther 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 c= an be extremely small.=C2=A0 Remember, each bit is measured in micrometers = -- about 2 micrometers, IIRC for QIC and around 10 for =C2=BD= " formats -- again, and I would need to check the ANSI spec, which is = not handy.=C2=A0 But this is a huge space savings even with a smallish bloc= k (512) -- again - this was lifted from disk technology of the day which ha= d 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].=C2=A0 =C2=A0First, the data bloc= k format would have to be variable to 4 sizes, and second, the preamble wou= ld need to encode and write what size block to expect on read.=C2=A0Unfortu= nately, that document does not say much more about the physical tape format= other than it can use cartridges=C2=A0 "similar=C2=A0to ANSI Standard= X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11 trac= ks, 8000 bpi" recording density (/w 10000 flux reversals per in), usin= g a "single track NRZI dat in a serpentine pattern, with 4-5 run lengt= h limited code similar to GCR."=C2=A0

That said, most modern S= W 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 pr= ogram 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.=C2=A0 =C2=A0My= 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=C2=A0forced to send it 51= 2-byte blocks.=C2=A0

So, while you may define blocks of different s= izes, unlike =C2=BD", 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.= ,=C2=A0 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 fini= shed, it's fixed 512-byte blocks on the tape.


=
One other thing is WRT to QIC, which differs fro= m other schemes.=C2=A0 I previously mentioned tape files - a feature of the= =C2=BD" physical tape formats not typically supported for QIC tapes.= =C2=A0 QIC has an interesting feature that allows a block to be rewritten a= nd replaced later on the tape (see the section of spec/you user manual WRT = for "rewritten" or "replacement "blocks).=C2=A0 =C2=A0 = I've forgotten all the details, but I seem to remember that features we= re why multiple tape files were difficult to implement.=C2=A0 =C2=A0Someone= 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 st= andard =C2=BD" tape driver could not be just cloned for the QIC driver= .
3D""=E1=90=A7
3D""=E1=90=A7
3D""=E1=90=A7
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Re= ply Online (#3631) | Reply To Group =20 | Reply To Sender =20 | Mute= This Topic | New Topic
Your= Subscription | Contact Group Own= er | Unsubscribe [clemc@ccc.com]

_._,_._,_

--00000000000032d980060dd51931--