> In normal testing, 5 Gb/s should yield around 500 MB/s
Wow 90% overheads?
Wow 90% overheads?
so about 20% overhead... I would not be dissatisfied with 500 MB/s result on a theoretical 625 MB/s bus.
So you have a 5Gb/s physical signal, then a 25% encoding overhead, for a raw data throughput of 537MB/s.
Once framing and protocol overhead are taken in account, mid-400s effective is probably a good result.
I can remember losing a USB drive that way, even though it was using a journaling filesystem.
ZFS does have defensive mechanisms, like doing a read after write to try and be sure that what is written is actually committed to disk, but if the storage controller chooses to serve that out of cache then that could be a lie too. It's the old "trusting trust" predicament, there's no way for hardware higher in the stack to prove that lower levels aren't simply a tower of lies, only instead of viruses it's flush.
That said, in practice very little hardware is actually a giant tower of lies. Flash drives typically do not have enough of a controller to actually cache anything, thus no real capability to lie about writes/etc. SSDs do, but they also generally obey the expected behavior around flushing actually flushing and not just lying about it.
RAID controllers and similar are the danger zone, because they may have cache and may lie to the CPU about it on the assumption that it actually will eventually be flushed, and that's the dangerous thing.
Is anyone testing for these kinds of things?
https://www.rroij.com/open-access/implementation-of-link-lay...
USB 3 uses CRC-16, still more than good enough for single bit flips.
Anyway, it still sucks that I couldn't find the exact reason for the error in the logs.
(... and a byte is not always 8 bits)
https://en.wikipedia.org/wiki/8b/10b_encoding
A byte is also referred to the smallest addressable unit. Which in most cases is 8 bits but many (I guess mostly niche architectures) have much larger characters/bytes, and is still very much relevant.
But probably for all practical purposes in modern era, we can safely assume it's always 8 bits.
Kibibyte (KiB)
1,024¹ = 1,024
Mebibyte (MiB)
1,024² = 1,048,576
Gibibyte (GiB)
1,024³ = 1,073,741,824
Tebibyte (TiB)
1,024⁴ = 1,099,511,627,776
Pebibyte (PiB)
1,024⁵ = 1,125,899,906,842,62
I know next to nothing about modern serial protocols, but nevertheless as a rule of thumb, and absent any other information, I tend to use 10 bits per byte when converting bits per second to bytes per second.
Saves disappointment if nothing else.
Recent standard revision (USB 3.1 Gen 2, as well as USB 3.2 Gen 2x2) switch to a more efficient 128b/132b encoding (https://en.wikipedia.org/wiki/64b/66b_encoding), with ~3% encoding overhead rather than the historical 25.