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 10447 invoked from network); 31 Dec 2023 19:30:39 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2023 19:30:39 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 5AC9C402CE; Mon, 1 Jan 2024 05:30:38 +1000 (AEST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by minnie.tuhs.org (Postfix) with ESMTPS id C131F40276 for ; Mon, 1 Jan 2024 05:30:30 +1000 (AEST) Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-680b1956ca4so2820496d6.3 for ; Sun, 31 Dec 2023 11:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1704051029; x=1704655829; 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=5sSTMYKOFqrtG4hVY7O7YRVQiVgCcll1ASjKiSYWTFs=; b=VHqEOXDt46z8BEmMvbg1uS5ObTBuZ64sv/008AR3KvA906lrVOYd1yZbh+3wWiuEzj Pj0r8FyWri+xhwdaWJgTJwp8lTXZZlF16MwausfiAVg1dgL4DGxvtll8E+6lM/uhLKJl b6ii3fXzHTq5xYEBaBJFOZHzeNsk/GMKn76nA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704051029; x=1704655829; 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=5sSTMYKOFqrtG4hVY7O7YRVQiVgCcll1ASjKiSYWTFs=; b=BBF6wD9ob9zcvlQgGc+hSMp8DcAfstnVzZLD5/TKZ6V/i57B7aDhVWacWlQjyWng1Q EJZ5Jsoxp9bDiGLttlZyoPjJSWERiiN0Ao0RSeiq8VnEZxj+itEgvcHQiV9qy9UrJaHm JP22cLlprsCd9BR/VFobRO0pUFwWGesLl4jXza6oNt2Kz2K3ViJHKBFtSGlhGwan8Fts 0yKjZoDShipODKTZdYlKzCSOeT0tIVO2PwyMW5BSpxtY6eGPcxMDYQGZQQ9cgTlKnhjI wSzB4t7Wk4nqcHcfaRpVngOUAPzFV0tiw+7UeXNnCi7KamGyH9ZClNvVSBlLcWtuVcmu wOjA== X-Gm-Message-State: AOJu0YwL6ND76D7Pa1Hp8Ed71+ZbglOtfrmE/86Xn0WdZY4Wi8z6H0q3 apUVMdttCVPANbe+VC8z5ECxMkfkpvJ5jpKXtV3Z1YdHcULc X-Google-Smtp-Source: AGHT+IEP6h1Zoqvl25Pp8mpo9fKX8IMPVqbapSQW7fD0HmqG6LyXxadTPSAlP8szLVLNN/vSIwiEyaLQDlbs9l/xPp4= X-Received: by 2002:a05:6214:e8c:b0:67f:288c:81d2 with SMTP id hf12-20020a0562140e8c00b0067f288c81d2mr21683248qvb.34.1704051029434; Sun, 31 Dec 2023 11:30:29 -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> In-Reply-To: <17A5C98F69111E59.18542@groups.io> From: Clem Cole Date: Sun, 31 Dec 2023 14:29:53 -0500 Message-ID: To: simh@groups.io Content-Type: multipart/alternative; boundary="00000000000049f5f2060dd34cf6" Message-ID-Hash: CTK43TJLCIOYEGPG6VOTQH5Z4WGJACFP X-Message-ID-Hash: CTK43TJLCIOYEGPG6VOTQH5Z4WGJACFP 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: --00000000000049f5f2060dd34cf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Small PS below... On Sat, Dec 30, 2023 at 9:27=E2=80=AFPM Clement T Cole via 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 size= s > on each tape. Streamer formats don=E2=80=99t traditionally allow that be= cause 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 =C2=BD" formats -- again, and I would need t= o 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 =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.*, 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 fo= rmats 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 =C2=BD" tape driver could not be just cloned for the QI= C driver. =E1=90=A7 =E1=90=A7 =E1=90=A7 --00000000000049f5f2060dd34cf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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&= gt; wrote:

I = did not say that or imply it. =C2=A0 But variable vs. fixed blocking has im= plications on both mechanical requirements and ends up being reflected in h= ow the sw handles it.=C2=A0 Traditional 9-track allows you to mix record si= zes on each tape.=C2=A0 Streamer formats don=E2=80=99t traditionally allow = that because they restrict / remove inter record gaps in the same manner 9-= track supports.=C2=A0 This increases capacity of the tape (less waste).=C2= =A0

In my explanation, I may have been a tad confusing.=C2=A0 =C2=A0When 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 CR= C and postamble" [the standard previous defines a data black o= s 512 consecutive bytes] -- i.e., if you put an o'scope on the t= ape head and looked at the bit stream=C2=A0(see page 16 of QIC-120 Rev F - = =C2=A0Section 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-b= yte blocks).

STOP/STOP does something similar but encodes the LRECL= used [I don't have the ANSI tape standard handy - but I remember seein= g a wonderful picture of all this from said documents when I first was educ= ated about tapes in my old IBM days ~50 years ago].=C2=A0 =C2=A0After 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.=C2=A0 The IRC distance is something like 5-10 mm [whic= h is a great deal compared to the size of a bit when using GCR encoding (wh= ich is what 6250 BPI and QIC both use). These gaps take space (capacity) fr= om the tape, so people tend to write with larger blocking factors [UNIX tra= ditionally uses 10240 bytes-=C2=A0other systems use other values - as I sai= d, I believe the standard says the max is 64K bytes).

Since streame= rs (like QIC tape) are supposed to be continuous, the QIC inter-records gap= s resemble fixed disk records and can be extremely small.=C2=A0 Remember, e= ach bit is measured in micrometers -- about 2 micrometers, II= RC for QIC and around 10 for =C2=BD" formats -- again, and I would nee= d to check the ANSI spec, which is not handy.=C2=A0 But this is a huge spac= e 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 b= locks by then.

<= font color=3D"#0000ff">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 th= e TK25 user manual says it supports four different block sizes [1K/2K/4K/8K= ].=C2=A0 =C2=A0First, the data block format would have to be variable to 4 = sizes, and second, the preamble would need to encode and write what size bl= ock to expect on read.=C2=A0Unfortunately, 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 tracks, 8000 bpi" recording density (/w= 10000 flux reversals per in), using a "single track NRZI dat in a ser= pentine pattern, with 4-5 run length limited code similar to GCR."=C2= =A0

That said, most modern SW will allow you to write different size record sizes (LRECL) in the user software, but the QIC dri= ves and I believe things like DAT and Exabyte will only write 512-byte bloc= ks, 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 la= st 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 th= e driver is=C2=A0forced to send it 512-byte blocks.=C2=A0

So, whi= le you may define blocks of different sizes, unlike =C2=BD", it will a= lways be written as 512-byte blocks.

That said, using larger record= sizes in your application SW can have huge performance wins (which I menti= oned 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 finished, it's fixed 512-byte blocks= on the tape.


One oth= er thing is WRT to QIC, which differs from other schemes.=C2=A0 I previousl= y mentioned tape files - a feature of the =C2=BD" physical tape format= s not typically supported for QIC tapes.=C2=A0 QIC has an interesting featu= re 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).=C2=A0 =C2=A0 I've forgotten all the details,= but I seem to remember that features were why multiple tape files were dif= ficult to implement.=C2=A0 =C2=A0Someone who knows more about tapes may rem= ember 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 cou= ld not be just cloned for the QIC driver.
3D""=E1=90=A7
=3D""=E1=90=A7
3D""=E1=90=A7
--00000000000049f5f2060dd34cf6--