Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About
 It?
Date: Sat, 24 May 2025 09:23:48 -0700
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <100srqk$pos5$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>
 <100oetb$c5c7$1@paganini.bofh.team> <100q47d$3k7s2$1@dont-email.me>
 <jwv8qmncayc.fsf-monnier+comp.arch@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 24 May 2025 18:23:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="38093b3af8a028674de0c3d75fdfd883";
	logging-data="844677"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Py6obPQyp0sLIfjpUWvhDR5XjXXsX1+0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:IeJrl0aV3PA4LQLYc1hTV0Mpuzc=
In-Reply-To: <jwv8qmncayc.fsf-monnier+comp.arch@gnu.org>
Content-Language: en-US
Bytes: 5271

On 5/23/2025 2:03 PM, Stefan Monnier wrote:
> Stephen Fuld [2025-05-23 08:28:44] wrote:
>> On 5/22/2025 5:18 PM, Waldek Hebisch wrote:
>>> It is pretty clear that due to drive mechanics track cache/buffer
>>> is useful.
>> Pretty clear to everyone except one person. :-)
> 
> 🙂
> 
>>> However, the real question is about size: how big
>>> should it be.  For "consumer" drives I see claims of 256 MB
>>> cache.  Given rather optimistic 200 MB/s transfer rate it is
>>> about 1.25s of drive data, that is 80-150 rotations.  I would
>>> expect that say 4 tracks should be enough for reading.  For
>>> writing one could use few more tracks.  Still, advertised cache
>>> sizes seem to be much bigger than necessary.
>> It's not just the rotations, but the seek time. So your example is fewer
>> "operations" than the 80-150 you get when just including rotations.
> 
> I don't understand what you're getting at, here.
> I think Waldek's argument is that 256MB corresponds approximately
> to the amount of data stored in 80-150 tracks, and seek time doesn't
> change that fact.

Yes, I didn't express myself well.  :-(  And once again, I have to say 
that my information may be obsolete.

I think it is useful to separate talking about read data from write 
data.  For read data, as with any cache, more is always better than 
less, though with diminishing returns.  Why pick 1.25 sec as the "cut 
off point"?  If the host re-references data that it hasn't read for say 
3 seconds, having it in cache still saves, probably a seek time and on 
average 1/2 rotation time.  Plus, it means the heads will be free to 
handle other requests.  All of this is standard cache benefits.  I see 
no reason to limit the cache size and reduce this benefit.


>> And if you are caching writes, more cache gives you more blocks to choose
>> from when optimizing the write back order, which reduces the time to write
>> them all back.
> 
> IIUC, for SATA drives, NCQ is still limited to 32 in-flight commands, so
> unless the drive is allowed to do write-back caching it seems the amount
> of space used for write-buffering is likely small (compared to 256MB).
> [ Unless it is common for individual write commands to cover multi-MB
>    chunks of data?  ]


For write data, I was unaware of the 32 operation limit.  I was used to 
SCSI, which, IIRC was larger, and for server type applications, where 
some sort of UPS is more common, the site may choose to enable write 
caching in the disk.  For a disk vendor, given the small cost of the 
DRAM, it is an easy choice.


>> The larger DRAM is a small component of drive cost, so the
>> manufacturers think it is worth including more.
> 
> In some markets (e.g. home routers), the size of DRAM seems to be enough
> of a cost factor that it took many years until reaching 256MBs, even
> though those boxes *need* that RAM for all kinds of purposes (the 128MB
> of my current home-router seems to be its main source of instability).
> but HDDs are pretty damn expensive beasts nowadays (because prices have
> not gone down for the last 10 years or so), so I guess that makes
> the relative cost of 512MB of DRAM "negligible"?

I can't comment on routers, but for disks, while the cost of the disk 
may not have come down, increasing capacity allows reduced cost per 
gigabyte.  A substantial portion of the cost is not subject to Moore's 
law (e.g. drive motor, magnets and arm assembly, etc.) and some capacity 
increasing technologies cost more (but not enough more to overwhelm the 
capacity advantage).



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)