From Newsgroup: comp.arch

On 9/29/2026 12:01 PM, Torbjorn Lindgren wrote:

BGB <[email protected]> wrote:

Well, for me, it is like the weirdness of seeing videos where people
claim read/write speeds on NVMe SSD's that seem to encroach on the
territory I see when benchmarking "memcpy()" style operations.

As others noted the CPU generally don't touch the data for that kind
of test, it's basically a PCIe bandwidth & overhead test if the SSD is
fast enough.

One thing to remember is that for write the quoted speed won't be
sustained for very long unless you're buying extremely expensive
enterprise SSDs - most SSDs has a pseudo-SLC mode cache and then
"folds" the data to TLC or QLC.

Tom's Hardware always test SSDs "properly" (IMHO), so lets look at a
review of random semi-recent (Dec 2025) high-end consumer SSD, the
Corsair MP700 Pro XT [1].

For the 2TB model Corsair lists up to 14900MB/s read and 14500MB/s
write and someone mentioned it being capable of 3.3M IOPS but I can't
find a quote for that.

The ones Tom's lists is a bit lower at 12+GB/s and 2M IOPS but I have
no doubt Corsair really did manage to get the numbers they advertise.

But the section that I always also check is the "Sustained Write
Performance and Cache Recovery".

As usual for SSDs the sustained write performance is COMPLICATED - it
pretty much always is unless the interface is very limiting (IE SATA).

In this case the 2TB drive ran in pSLC mode at 13.7GB/s for 16 seconds (~220GB, using ~660GB of TLC flash cells), then switched to direct
write to the TLC flash at 4.2GB/s but there's intermittent short
period where the performance falls down to 1.96GB/s, showing the SSD
has to do "folding" (convert the pSLC data to native TLC) to free
flash storage.

The pSLC mode is there to make most normal operations lightning fast,
in most cases it'll have plenty of time to run the folding in the
background so it's not noticeable.

Most SSDs used dynamic pSLC cache using some (or all) of the free
flash, so the max cache size will shrink if the SSD is full.

I'm rather impressed by those numbers but then it's very much not a
cheap drive.

Once you get into cheaper drives the sustained write performance often
tanks a LOT, glares at an old Samsung 870 QVO (SATA QLC from 2020)
which when full has a sustained write speed of 35-40MB/s outside the
now minute (full, remember) pSLC cache. And that's far from the worst
QLC drive I've seen.

Flash has gotten faster since then, when I checked a recent budget
PCIe 5.0 x4 QLC drive the sustained write speed was shown as ~200MB/s
which was about in my expected range.

The manufacture advertises 5.0GB/s read and 4.2GB/s write speed for
this drive and I have no doubt they're not lying about that, I'm sure
it hits that advertised write speed until the pSLC cache runs full.

And to be honest, for a lot of people it's probably go work fairly
well at least if they don't fill it above say 80-90%. Yes, there will slowdowns when installing large programs and it's also a LOT cheaper
than the premium TLC drive above.

I do consider it misleading to not list the sustained write speed but
I'm not listing the vendor because NO ONE list it except for high-end Enterprise SSDs.

Yeah, I don't know, as I don't have one...


But, either way, it implies IO speeds that somewhat exceed the
single-core "memcpy()" on my PC.

Then again, had noted not to long ago that the my main PC's
single-threaded memcpy score is beaten by a laptop with a "Core i7 8th
Gen".

This laptop being fast at single-threaded tasks, though seems to more
quickly lose speed with multiple threads.

Well, and much faster than the 300 MB/s I see with a SATA SSD (where
both the SSD and MOBO support SATA3, which theoretically has a higher
limit, but in testing I see 300MB/s, or the SATA2 limit).

I have plenty of older SATA MLC or TLC SSDs which will fill the
interface in either read or write basically forever, because the
native write speed to the flash significantly exceed the interface
speed so there was no reason to implement a pSLC cache, it's all
native writes.

In practice this translates to 550-560 MB/s read or ~520 MB/write. If
you're getting 300MB/s you're actually exceeding the capabilities of a
SATA II link (even if only by a bit) :-)

When I look at it in an HDD tool, it basically does a flat 300 MB/s with pretty much no variability.

In this case, it was a fairly recent SSD made by Samsung to replace an
older failing SSD (made by Sandisk). Had imaged over the contents from
the old SSD to the new one.

Drive is listed as "Samsung EVO 1TB".


In this case, the HDD utility reports the drive interface as SATA 2.0
(along with all the other SATA drives also being listed as SATA 2.0).

Dunno the specifics, this is just what I seem to be seeing here.

Theoretically, the MOBO chipset claims SATA 3.0 support.


Checking:
Power on hours: 18531, ~ 2 years.

Curiously, read speed not really any faster than the old one, which also
got 300 MB/s, but IIRC was slower at write speeds.


Checking a few of my HDDs:
6TB WD Red : 125-184 MB/s
4TB WD Red : 169-178 MB/s
2TB HGST Ultrastar: 180-201 MB/s


The HGST drives being some second-hand (retired) server drives (still
newer than the drives they replaced; *1). Currently, my 4TB WD Red is
older than these drives, but my SSD and 6TB drive are younger.


*1: IIRC around 116 and 100 kilohour.

Though, does have an idle thought:
Assuming a drive were hermetically sealed and used magnetic bearings and similar, how long could such a drive keep running?...

Say, could one make a drive with megahour lifespans?...
Say, a drive where humans expire faster than the drive wears out?...


So, say:
Drive is sealed, with an inert Ar atmosphere;
Platter spindle is magnetically levitated during operation. Possibly the spindle uses a hybrid SRM design, with conical ends. These travel inside
of aluminum conical indents, and when the rotor spins up it creates a repulsive force against the aluminum indents. Could maybe have a coating
on the inside of the cones to deal with spin-up / spin-down; where the levitation would cease, but a fairly thin gap (to limit slop).
Potentially, both surfaces are coated in tungsten or similar (for high abrasion resistence), and/or PTFE (where WC on WC would still be weak
against sudden contact or vibration, and a WC/PTFE interface could
absorb shock a little better). Well, or most of the interface is WC,
with PTFE at the tips of the cones as this is the point where sudden
contact is most likely (though a lot depends on acceleration vectors
here). Well, or a WC+PTFE / W interface.

Possibly, the magnet is moved to the arm, and the voice could is
external, with the head arm powered inductively and using an optical
link to the controller (to avoid metal fatigue in a flat-flex cable).
Head-arm bushing could also be tungsten carbide or similar (on a
tungsten shaft). Possibly the ends of the shaft (and head shaft bearing)
use PFTE interfaces to reduce risk of damage from G-shock, ... Though,
making the heads/platters resistant to G-shock being a harder problem.

The LEDs/photodiodes would need to operate at a fairly low power though.

Probably also use older and more robust process nodes so that metal
migration and similar are less of an issue.


But, alas, if built, would probably be too expensive...


...

Not sure if anyone still manufacturer/sells "good" SATA SSDs?, the
market has kind of moved on.

1. https://www.tomshardware.com/pc-components/ssds/corsair-mp700-pro-xt-2tb-ssd-review

Dunno there...


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


[email protected] (Scott Lurndal) posted:

BGB <[email protected]> writes:

On 9/28/2026 10:29 AM, Scott Lurndal wrote:

BGB <[email protected]> writes:

On 9/26/2026 4:31 PM, MitchAlsup wrote:

Either way, quite different from how HDDs were once done on x86:
Wait for IRQ;
Do a bunch of IN/OUT instructions to move the data via IO ports.

All the mainframes at that time had been using DMA for a couple
of decades.

The youngest mainframe that did not have DMA was the CDC 7600--where
the peripheral processors performed this task {roughly a gaggle of
PDP-8s doing your I/O DMA}. Even here, the CPUs were not moving disk
buffers to/from memory.

In the CDC 6600 era, the PPs performed the Operating System Duties,
In the CDC 7600 era, some of the OS functions were done in the CPU.
--- Synchronet 3.22a-Linux NewsLink 1.2