5 ms·
> In normal testing, 5 Gb/s should yield around 500 MB/s Wow 90% overheads?
by chrisseaton 5y ago
> In normal testing, 5 Gb/s should yield around 500 MB/s
Wow 90% overheads?
- jon_adler 5y agoBits to bytes means dividing by 8.
- tjoff 5y agoJust to add for clarity, b is used for bits and B for bytes. Though they are often mixed up. (... and a byte is not always 8 bits)
- mccorrinall 5y agoI believe the byte changed its meaning like many words did in the past. To a lot of younger developers a byte is synonymous with an octet.
- JadedBlueEyes 5y agoIn the CS tests for every UK exam board, a byte is always 8 bits
- jon_adler 5y agoA byte has been synonymous with an octet for as long as I can remember. I found a Wikipedia article [1] that describes the transition of a byte meaning the number of bits to encode character of text to an octet. [1] https://en.wikipedia.org/wiki/Units_of_information https://en.wikipedia.org/wiki/Units_of_information
- saagarjha 5y agoIn C it’s not when CHAR_BIT != 8.
- tjoff 5y agoIt does depend on context though. Transports often use 8b/10b, which is why SATA 6Gb/s is also 600 MB/s. https://en.wikipedia.org/wiki/8b/10b_encoding 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.
- mccorrinall 5y agoI love your comments! Always learning something new. (this time about SATA)
- can16358p 5y agoI just had to google "is byte always 8 bits" so see that in historical context it wasn't always the case. But probably for all practical purposes in modern era, we can safely assume it's always 8 bits.
- huhtenberg 5y agoUnless you are a disk drive vendor, in which case you insist it's 10.
- can16358p 5y agoWhy? Assuming a byte being 10 bits instead of 8 bits would actually make the drive capacity lower in terms of bytes (of course not physically but for marketing), which a vendor probably doesn't want.
- rileymat2 5y agoI am not sure what the op is talking about with bytes, but it could be powers of 2 v. powers of ten for kb/mb/gb.
- sigio 5y agoYeah, that's the kibibytes vs kilobytes / gibibytes vs gigabytes diffence... Which adds up to ~7% difference in capacity when talking about GiB/GB, and even 12.5% when talking about PiB/PB 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
- doctor_eval 5y agoI'm old enough to remember parity bits and FEC, so I know that the number of bits per data byte might be 8, but the number of bits required to transmit a single byte might be more than 8, and the number of bytes needed to transmit a frame of data might also be higher than the number of bytes of payload within the frame. 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.
- masklinn 5y agoYou're pretty much on the dot: what you're thinking of is 8b/10b encoding (https://en.wikipedia.org/wiki/8b/10b_encoding https://en.wikipedia.org/wiki/8b/10b_encoding) and it's exactly what USB uses historically. 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 https://en.wikipedia.org/wiki/64b/66b_encoding), with ~3% encoding overhead rather than the historical 25.
- RedShift1 5y ago5 gigabit/s = 0.625 gigabyte/s = 625 megabyte/s so about 20% overhead... I would not be dissatisfied with 500 MB/s result on a theoretical 625 MB/s bus.
- masklinn 5y agoFWIW it's actually 500MB theoretical (ideal), because USB uses a 8/10 encoding[0], until 3.1 Gen 2 which switches to a 128/132 encoding[1]. 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. [0] https://en.wikipedia.org/wiki/8b/10b_encoding https://en.wikipedia.org/wiki/8b/10b_encoding [1] https://en.wikipedia.org/wiki/64b/66b_encoding https://en.wikipedia.org/wiki/64b/66b_encoding
- amelius 5y agoWhat sucks, however, is that you can transfer 1TB to a USB drive correctly, and then finally have a bit-error that spoils the entire transfer and might even corrupt your drive. Happened to me several times during testing on different machines and with different cables and drives (luckily no real data was lost, but USB is now sort of banned from my office for use with external harddrives). Any sane protocol would be able to deal with such a low error rate, and finish a data transfer without problems.
- RedShift1 5y agoAre you sure it's a USB problem and not something else? Did you reduce all possible variables - ie how scientific were you in determining USB was the problem and not something else?
- amelius 5y agoI think I tested quite thoroughly on very recent Linux versions with Rsync. Of course it is difficult to pinpoint the real culprit with certainty, but USB has no error correction, and that makes it the prime suspect here.