Hacker News Reader

Comment by jmpman | Hacker News Reader

I would have preferred a review that wasn’t quite as dismissive. SSDs have periodic higher read latency that could impact audio playback if the host buffers aren’t large enough. The flash translation layer periodically reshuffles data, even when the workload is just reads. I expect this drive is duplicating the data internally, and pivoting back and forth between the two copies, targeting one which is not performing garbage collection at that time. This mechanism would result in more consistent, lower latency read performance. It might even be more advanced than that - triple mirroring the data - hardening the data to two copies first, while serving the non impacted read blocks from the third copy. Although the other SSD claims do sound ridiculous, consistent read performance is a nice feature. This type of capability is expected in enterprise storage, it may have some use in consumer class storage applications, besides just audio.

View on HN

For pure listening, latency is totally irrelevant as long as the buffers are large enough, and that's a software thing. Heck, one complete audio CD fits uncompressed in one GB of RAM...

>SSDs have periodic higher read latency that could impact audio playback if the host buffers aren’t large enough.

In what scenario is audio streamed direct from an ssd rather than memory?

I think your mental model of how SSDs work is a bit inaccurate. Read operations will not trigger wear leveling during normal use. Reads will only cause the SSD to start moving data around if there's a correctable ECC error with the read, prompting the drive to write a fresh and corrected copy. Correctable read errors can crop up from data degradation over time, or from read disturb errors (analogous to DRAM rowhammer). Neither of those causes are even remotely likely unless you have a highly atypical workload that does not at all fit an audio use case. The probability of a latency spike due to these causes leading to an audible glitch is small enough that it should be entirely ignored.

If you're worried about read latency on a scale that could affect an audio workload, the only change to the SSD that might be relevant would be disabling the low-power idle modes, which can take a while to wake up from. Enterprise SSDs have other measures to manage QoS targets that are tighter than what an audio use case requires, and those features are only necessary when dealing with a workload that includes a heavy volume of write operations—not relevant to audiophiles. And enterprise drives definitely don't need to duplicate all your data as a way of avoiding high read latency; it's possible to suspend write operations in order to service a read request that needs to access the same physical block.

Do SSDs do background reads to refresh data as the charge slowly leaks or catch any other sort of corruption?

That's the kind of internal information that is seldom disclosed by SSD manufacturers. Toward the end of the planar NAND era there were several notable cases of vendors having to add background reads/scrubbing because data retention was quite poor with tiny planar TLC cells, and there were measurable performance losses when reading stale data due to the extra ECC required to recover the original data. There are also some enterprise drives or array appliances that have documented behavior where after a long period of being unpowered, they'll operate with reduced performance for a while while a scrub is done.

But for normal use cases, you're either writing enough data that everything on the drive ends up refreshed at least once or twice per year, or you're writing so little data that your flash is basically not getting worn out at all and the retention times will be extremely long, so you're left worrying about read disturb errors which are pretty unlikely to grow into uncorrectable errors without a rowhammer-like workload.

I'm pretty sure most consumer SSDs are not doing full-drive scrubs after every power loss, both because I've never seen evidence of that while measuring SSD power consumption and because it would be insane to do given that it is common for the SSD to be completely powered off every time you close the lid of your laptop.

You write that reads will not trigger wear leveling, and then you go on to explain multiple scenarios in which reads will trigger rewrites. Those rewrites can cause elevated read latency. I have done SSD code reviews with multiple SSD vendors, and there are some which will trigger wear leveling after a set number of reads, instead of waiting for elevated bit error rates. And yes, the elevated read latency should be in the order of 5ms, which shouldn’t impact a properly buffered audio application, but the world is full of incorrectly designed applications.

https://storageswiss.com/2019/04/18/not-achieving-the-ssd-pe...

As for enterprise drives, there are dozens of tricks to ensure lower latency. Reading from other members in an erasure code, read prioritization over writes. It all depends upon how low of latency you’re trying to achieve, and with what level of consistency.

My point was that this drive may be using some innovative techniques to achieve consistently low read latencies in a “consumer” class drive. Possibly novel.

> but the world is full of incorrectly designed applications.

No it's not. This particular kind of incorrectly-designed application cannot be prevalent if the kind of hardware it requires to function at all is still new and rare.

Minor audio glitches due to read latency never happen? My assertion is that there exist audio applications which incorrectly utilize buffers, which would then be improved by more consistent read latency.

> SSDs have periodic higher read latency that could impact audio playback if the host buffers aren’t large enough.

Buffering sufficient to deal with a CD reader losing tracking and needing to reacquire it, which takes an order of magnitude longer than all but the most pathological flash management scenarios, has been an utterly boring consumer-grade feature since the late 90s.

I'd worry more about electrical interference than read latency.

Reply on news.ycombinator.com