Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360
Date: Wed, 26 Jun 2024 01:00:42 +0300
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <20240626010042.00004d86@yahoo.com>
References: <s7r87j1c3u6mim0db3ccbdvknvtjr4anu3@4ax.com>
	<v5an0l$10bj$1@gal.iecc.com>
	<87le2vatq4.fsf@localhost>
	<v5asis$p33t$1@dont-email.me>
	<v5dfkf$1h3e$3@gal.iecc.com>
	<v5dpa8$1ej8a$1@dont-email.me>
	<20240625111904.000018d2@yahoo.com>
	<IiBeO.85766$xKj1.61723@fx09.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Wed, 26 Jun 2024 00:00:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a2e5fa8ac7dd2a86a15de65085401f93";
	logging-data="1782844"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19q0vX5CTPeXNmnaLF4Cx7/oICilAEE9Vo="
Cancel-Lock: sha1:zVmQFH2+7QxlZ4V7w3F1WA0ndoM=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 3564

On Tue, 25 Jun 2024 11:24:03 -0400
EricP <ThatWouldBeTelling@thevillage.com> wrote:

> Michael S wrote:
> > On Tue, 25 Jun 2024 08:49:43 +0200
> > Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> >  =20
> >> John Levine wrote: =20
> >>> According to Lawrence D'Oliveiro  <ldo@nz.invalid>:   =20
> >>>> How much of theoretical disk bandwidth was the filesystem capable
> >>>> of using? Because I know early Unix systems were pretty terrible
> >>>> in that regard, until Berkeley=C3=A2=E2=82=AC=E2=84=A2s =C3=A2=E2=82=
=AC=C5=93Fast File System=C3=A2=E2=82=AC=C2=9D came
> >>>> along.   =20
> >>> My recollection is that if you were using QSAM with multiple
> >>> buffers and full track records it wasn't hard to keep the disk
> >>> going at full speed. Later versions of OS do chained scheduling
> >>> if you have enough buffers, doing several disk operations with
> >>> one cnannel program.   =20
> >> Even on (MS)DOS it was easy to saturate the hard drive from a
> >> single program, you just needed large enough (i.e. at least a full
> >> track each) buffers.
> >> =20
> >=20
> > I am not sure that "saturate the hard drive" is a correct wording.
> > According to my understanding, [when within track] hard drives used
> > in early PCs were more capable than hard disk controllers (Xebec
> > 1210 in XT, I don't know what was used before XT). In turn, disk
> > side interface of disk controller was likely more capable than its
> > system bus side. Now, those are just feelings, I can't find hard
> > data to back it up.=20
> >> I did end up making special file/record layouts which were
> >> optimized for this, using exactly 4kB for each header+bitmap
> >> record.
> >>
> >> Terje =20
>=20
> According to this the interface to the ST506/ST412 drives from early
> 1980's could handle 5 Mb/s and the avg track seek time was 170 ms
> (later 85 ms).=20
>=20
> https://en.wikipedia.org/wiki/ST-506#History
>=20

Thank you. I didn't realize that PC HDs of early 80s were *that*
slow.

> The 8-bit PC bus was 8 MB/s so there should be no
> technical reason for not keeping *multiple* such drives fully busy
> (seeking or transferring) while concurrently executing code.

8 MB/s sounds fast. I think, even for XT 2 MB/s is more realistic. Less
than that for original PC.