Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Vir Campestris <vir.campestris@invalid.invalid>
Newsgroups: comp.arch
Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About
 It?
Date: Tue, 20 May 2025 11:22:26 +0100
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <100hl52$26e2p$1@dont-email.me>
References: <vvnds6$3gism$1@dont-email.me>
 <edb59b7854474033c748f0fd668badaa@www.novabbs.org>
 <w32UP.481123$C51b.217868@fx17.iad> <vvqdas$g9oh$1@dont-email.me>
 <vvrcs9$msmc$2@dont-email.me>
 <0ec5d195f4732e6c92da77b7e2fa986d@www.novabbs.org>
 <vvribg$npn4$1@dont-email.me> <vvs343$ulkk$1@dont-email.me>
 <vvtt4d$1b8s7$4@dont-email.me> <2025May13.094035@mips.complang.tuwien.ac.at>
 <vvuuua$1mt7m$1@dont-email.me> <vvvons$3uvs3$2@dont-email.me>
 <1000nfp$2440u$1@dont-email.me> <1000pae$3uvs3$3@dont-email.me>
 <100bdhq$lhdb$3@dont-email.me> <87sel1jw9z.fsf@localhost>
 <100e28i$11n5t$1@dont-email.me> <100g5an$1q32t$1@dont-email.me>
 <100g9ip$1otvf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 20 May 2025 12:22:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="87891efd93e1c63910a2a7fe4c3a7418";
	logging-data="2308185"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+lLSC0ug/zQKtJQxp5HNkWA1xN2heldt4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:LIZmN4XcfMKAjH7EQdZ1awpSdRI=
In-Reply-To: <100g9ip$1otvf$1@dont-email.me>
Content-Language: en-GB
Bytes: 3538

On 19/05/2025 22:58, Stephen Fuld wrote:
> On 5/19/2025 1:46 PM, Vir Campestris wrote:
>> On 19/05/2025 02:41, Stephen Fuld wrote:
>>>
>>> It didn't make sense to, after executing the full track read, since 
>>> the disk was positioned at the end of the track, and you had a good 
>>> indication that it was a sequential file read, to start caching the 
>>> next track in anticipation of the next full track read?
>>
>> It might if the disk was idle. But if there is a queue from another 
>> process it probably will be better to do that instead.
> 
> I presume you know that the 3880 controller did not do what today we 
> call command queuing, so I think you were referring to a potential queue 
> in the host.  That being the case, the controller doesn't know if there 
> is a queue or not.  So given that, why not start reading record 1 on the 
> next track.  If a request comes in, you can abandon the read to service 
> the request - no harm, no foul.  If there isn't, and you subsequently 
> get a request for that track, it's a big win.  The only potential loss 
> is if you get a request for the track that was LRU and got pushed out of 
> the cache.
> 
> 
The only IBM machine I've ever even touch was a PC/XT - so no, I didn't 
know. That makes sense.

My mainframe background goes back to the ICL 2900 at the beginning of 
the '80s. There were two families of disc controllers, one of which did 
clever stuff like retries for the host (I don't remember if it cached) 
and the other one was dumb and cheap. The dumb one was becoming more 
popular at the time when I discovered the realities of working in tech 
and had practice in CV writing...

Andy

-- 
Do not listen to rumour, but, if you do, do not believe it.
Ghandi.