Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?
Date: Wed, 21 May 2025 17:19:47 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 52
Message-ID: <2025May21.191947@mips.complang.tuwien.ac.at>
References: <vvnds6$3gism$1@dont-email.me> <100bdhq$lhdb$3@dont-email.me> <91c8a31fc5d04a1fadf210b2dd6d4875@www.novabbs.org> <100e0it$19264$1@dont-email.me> <fa7e33d953bc6f545387d862e19c2bd2@www.novabbs.org> <100gipr$1sbnn$10@dont-email.me> <100h3jm$23ehu$1@dont-email.me> <jwv7c2bjqcx.fsf-monnier+comp.arch@gnu.org> <100j6pq$2fqhj$9@dont-email.me> <100j9e7$2gdpc$1@dont-email.me> <100jib4$2lgt3$6@dont-email.me> <100jj1u$2fpjs$2@dont-email.me> <f9nXP.500263$lbbb.302518@fx18.iad>
Injection-Date: Wed, 21 May 2025 19:55:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4778e2588f8bcbd8021b87932622a7a5";
	logging-data="3118911"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19m/ChtKkYQBtqo0QnI4nIf"
Cancel-Lock: sha1:WVauf5FwSeWb+M36QWs29jtMSdg=
X-newsreader: xrn 10.11
Bytes: 3925

EricP <ThatWouldBeTelling@thevillage.com> writes:
>I suspect some of Lawrence's concerns go back to the Win3.1 days,
>when HDD could now afford to expand the read/write buffer and improve
>their performance stats. Because the Parallel ATA interface was synchronous
>one way drives "improved" their performance stats was to lie and send back
>a fake ACK to writes until they had enough sectors to make up a whole track.

AFAIK there was no tagged command queuing in the (P)ATA interface
until pretty late in the game (and then it was not used by Linux
AFAIK).  So if the HDD had waited until the sector was on the platter
(and IIRC there was a way to switch the drive to such a synchronous
mode), anything that writes to the HDD would have been extremely slow:

Wait until the sector is found, write the sector, report success, get
the next command that writes the next sector, but now the head is
already past the sector and you have to wait for another rotation.

By contrast, if you return success as soon as the sector is in the
HDD's RAM, the OS can continue sending data, and the HDD can write the
data in any order that it deems appropriate; it does not have to wait
for a complete track or something, it can start writing right away,
and, of course, if there is a sequence of sectors in the cache, write
that sequence in one go.

I have written a test that checks how much HDDs can reorder writes,
and my results are that, for the pattern I tested, there is no bound on
the out-of-orderness that the drives exhibit if you don't ask for a
barrier or sync.  You can find the test software and the results of my
testing at

<http://www.complang.tuwien.ac.at/anton/hdtest/>

>Yes it risked scrambling the file system if one powered off too quick.
>But I gather DOS/Win3.1 FAT file system would do that enough on its own
>that the drive wouldn't be blamed.

Actually on MS-DOS the usual way to shut down the system was to turn
the computer off, or in case of floppy disks to just take them out of
the drive after the light has gone out, and the amount of breakage on
the file system level was not big.  I expect that the file system
synced pretty obsessively to achieve that.

>When I installed WinNT 3.1 (beta) in 1992 it came with explicit
>instructions that HDD must use write-through caching, which was
>enabled/disabled by a jumper pin on the drive.

SCSI or PATA?

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>