Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S 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: <87le2vatq4.fsf@localhost> <20240625111904.000018d2@yahoo.com> 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 wrote: > Michael S wrote: > > On Tue, 25 Jun 2024 08:49:43 +0200 > > Terje Mathisen wrote: > > =20 > >> John Levine wrote: =20 > >>> According to Lawrence D'Oliveiro : =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.