Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lynn Wheeler <lynn@garlic.com>
Newsgroups: comp.arch
Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360
Date: Tue, 25 Jun 2024 08:33:39 -1000
Organization: Wheeler&Wheeler
Lines: 43
Message-ID: <87jzic3m9o.fsf@localhost>
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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 25 Jun 2024 20:33:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0ac8877cc0bf64f765ef33c65ddecc1b";
	logging-data="1775279"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18EcRT6fI+6/a+bxKI7+MM7swvfVuqcCOY="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:+CdpGTuqUd8XDIx+hi+9ZSAOv6w=
	sha1:KLaG2TjeucqEruGOngj2/PjHX28=
Bytes: 3490

John Levine <johnl@taugh.com> writes:
> 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.

When 360/67 was delivered to univ. I was hired fulltime responsible for
OS/360 (tss/360 never came to production). Initially student fortran
jobs ran over a minute (had run under a second on 709 tape->tape). I
installed HASP which cuts the time in half. I then started redoing
OS/360 SYSGEN to carefully place SYSTEM datasets and PDS (program
library) members to optimize arm seek and multi-track search (channel
program used to searc PDS directory for member location) cutting another
2/3rds to 12.9secs. Student Fortran never got better than 709 until I
installed Univ. of Waterloo WATFOR.

when CP67 was 1st delivered to univ (3rd installation after cambridge
itself and MIT lincoln labs), all I/O was FIFO and page I/O was single
4k page at time. CMS filesystem was 800 byte blocks and was usually
single block transfer per channel program ... however if loading a
program image and had been allocated contiguous sequential, it would
transfer up to track worth in single channel program.

I redid disk I/O to ordered seek and redid page I/O to maximize page
transfers per revolution (at same arm position). For 2301 fixed-head
(paging) drum I got it from max around 70 4k/sec to peak of 270 4k/sec
(max transfers per 2301 revolution).

There was problem with CMS filesystem that pretty much did scatter
allocate (CMS sort of shared some CTSS heritage with UNIX going back
through MULTICS) ... so it was rare file that it happened to have any
sequentially allocated, contiguous records. Shortly after graduating and
joining science center ... and seeing what multics was doing on flr
above (science center was on 4th flr 545tech sq, multics was on the
5flr), I modified CMS filesystem to be 4k records and use a paged mapped
API (and the underneath page I/O support would order for maximum
transfers per revolution) ... and I also added to CMS program image
generation, an attempt to maximize contiguous allocation, which could
result close to max transfers/revolution in single channel program (when
loading program).

-- 
virtualization experience starting Jan1968, online at home since Mar1970