Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler 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: <87le2vatq4.fsf@localhost> 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 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