USB on M1 Macs isn't actually 10Gb/s? (Also definitely not USB4)

[Frieg]

I already own several usb4/TB SSD. Again, that was not the point of this thread!
I can really recommend the corsair EX400U btw

 

[PaulD-UK]

@Frieg
Out of interest I tried to replicate your result, using an M4 Pro mini and an M1 mini.

I don't get the same result.
Connecting two different USB 3.1 Gen 2 10Gbps enclosures with a Kioxia or Samsung NVMe 1TB SSD inside,
I get BlackMagic (5GB file size) connection R/W speeds of 750-850MB/s in all cases using the TB5 or TB4 ports of the minis, and also from the front USB-C ports on the M4 Pro mini.

Only using the USB-A ports on the M1 mini does the speed drop to below 400MB/s, but Sysytem Information still reports 'up to 10Gbps'.
So it may be the USB-A to USB-C cable I'm using, because it came from a 3.5" HD enclosure, so it may only be USB 3.0...

The enclosures I'm using all have RTL-9210B-CG controller chips, and the OWC Mercury Elite Pro mini enclosure you mention is using an ASM235CM chip.
More importantly, that enclosure is designed for a SATA 3 2.5" SSD, which can never reach 10Gbps speeds, so maybe using a 5Gbps cable?
The problem you have may be specific to your particular situation.

This original thread post was noting the problems with M1 Macs in the Big Sur era.
You berate Apple for being 'lazy' and 'pathetic', 'or don't want to implement the standard'.

You also say "That's not the point of this thread." about the post from @ubercool about the increase of TB4 peripheral speeds when connected to a TB5 Mac.

I see the two as interconnected.
If Apple hasn't managed to rectify a USB 3.x connection problem, my guess is that it could only be solved at the expense of the proper working of the high speed TB4/5 ports.
That is the real world we care about today.

USB 3.0/3.1 hasn't really worked as a 'standard' that is backward compatible, and Apple has only looked backwards when it doesn't impede 'going forward'.
So complaining about this isn't going to make a difference, we have to live with this. 😉

 

[MacCheetah3]

This original thread post was noting the problems with M1 Macs in the Big Sur era.

This appears like a significant observation.

As an update, the performance is ~720MB/s read and ~670MB/s write using AmorphousDiskMark (4GB) on front and rear ports of my M4 Pro Mac mini (macOS 15.5). It’s the same drive and enclosure I tested/reported earlier.

Because I now have an M1 Mac and I was curious, here are some results.

Tested products:

SSK Aluminum M.2 NVME SATA SSD Enclosure Adapter, USB 3.2 Gen 2 (10 Gbps) to NVME PCI-E SATA M-Key/(B+M) Key Solid State Drive External Enclosure Support UASP Trim for NVME/SATA SSDs 2242/2260/2280

SSK Aluminum M.2 NVME SATA SSD Enclosure Adapter, USB 3.2 Gen 2 (10 Gbps) to NVME PCI-E SATA M-Key/(B+M) Key Solid State Drive External Enclosure Support UASP Trim for NVME/SATA SSDs 2242/2260/2280

www.amazon.com

Silicon Power 1TB - NVMe M.2 PCIe Gen3x4 2280 SSD (SP001TBP34A60M28)

Silicon Power 1TB - NVMe M.2 PCIe Gen3x4 2280 TLC SSD (SP001TBP34A60M28)

www.amazon.com

The SSK enclosure does link at 10Gb/s when connected with a USB-C to USB-C cable on either port.
View attachment 1790541
As for the speed verification.. Well, it is faster than USB 3.0 benchmarks, but not by leaps and bounds.

Blackmagic Disk Speed Test - 5GB
View attachment 1790537

TechTool Pro 14 - 3GB and 1GB
View attachment 1790540
View attachment 1790539

Connect to the M1 Mac mini via USB A (3.0), the read is ~360 MB/s, write is ~370MB/s. In comparison, when the enclosure/drive was connected to my 2012 Mac mini, the read and write rates were ~495MB/s to 520MB/s.

I’m not sure why the write is generally a little faster on the M1 — especially because with Blackmagic the write value fluctuated massively as the test looped.

In conclusion, M1 Macs can establish a 10Gb/s USB link, however, the performance is underwhelming and less than with Intel Macs.

Why? Either bugs/inefficiencies with Big Sur’s I/O overall or with Apple’s arm64 versions of the drivers.

P.S. If there was already a post verifying 10Gb/s, this can be a confirmation.

8b/10b is the encoding of data on the wire used by USB 3.0 (and many other things such as PCIe, SATA, and DisplayPort).
https://en.wikipedia.org/wiki/8b/10b_encoding

5Gbps * 8b/10b = 4 Gbps = 500 MB/s. So the fastest speed you can expect from USB 3.0 is less than 500 MB/s (approximately 460 MB/s)

Faster protocols such as Thunderbolt, PCIe 3.0, USB 3.1 gen 2, USB4, use more efficient encodings such as 64b/66b, 128b/130b, 128b/132b
https://en.wikipedia.org/wiki/64b/66b_encoding

When testing maximum bandwidth, it's probably best to use a benchmark that returns the highest numbers - I believe AmorphousDiskMark.app does that.
For testing shared bandwidth, ATTO Disk Benchmark.app can test multiple devices at the same time without having to create a RAID 0.

As for USB to NVMe enclosures - I don't think there are any that can't do 1000 MB/s no matter how cheap. I have these ones:
https://plugable.com/products/usbc-nvme
https://www.newegg.ca/orico-tcm2-c3-bk-bp-enclosure/p/0VN-0003-001D8

 

[platinumaqua]

OK i "solved" the "mystery" aka the typical Apple-patheticness by myself with an easy test:

I connected a dell dockinstation to the MacBook and the OWC to the dock and voila, the OWC reports with "up to 10Gb/s"

If I connect it again to the Macbook directly, I'm back to "limited to 5GB/s"

So here we are, the 4th Apple Silicon Generation and they couldn't care less so far to resolve this annoying bug.

That's the workaround I've found for my M1 Mac. Need to use a dock with an external USB controller. Some modern docks will tunnel the host's USB controller so such problems will still occur when plugged in to such docks.

It's the little things like this that made me lose interest in the Apple Silicon Macs, since Apple doesn't care enough to fix the bugs they've created.

 

[pshufd]

That's the workaround I've found for my M1 Mac. Need to use a dock with an external USB controller. Some modern docks will tunnel the host's USB controller so such problems will still occur when plugged in to such docks.

It's the little things like this that made me lose interest in the Apple Silicon Macs, since Apple doesn't care enough to fix the bugs they've created.

I think that lots of people have tried to resolve this particular issue and I can understand Apple's approach on not supporting all of the USB 3.* speeds. If you want more speed, go USB4.

 

[platinumaqua]

I think that lots of people have tried to resolve this particular issue and I can understand Apple's approach on not supporting all of the USB 3.* speeds. If you want more speed, go USB4.

It is frustrating because USB 3.x Gen 2x1 (10Gbps) is one of the speeds Apple explicitly state they support in the marketing materials, unlike the very rarely used USB 3.2 Gen 2x2 (20Gb/s)

 

[Alameda]

Could be related to USB4 vs. USB 3.x spec.

USB 3.1 Gen 10 GB is I think multi-lane (2x 5GB lanes - it's also called USB 3.1 Gen 2x2 for 10 GB I think), maybe USB4 is not.

USB4 is very similar to thunderbolt, and it may not work in a backwards compatible way with USB3.x in multi-lane.

Which means a single lane at USB 3.x will only get you 5 gigabit, despite the USB4 interface being faster (in a single lane) - but only when running in "USB 4" mode with a USB4 device.


Would also explain why you get full speed through the dock - you're going thunderbolt to another USB 3.x controller on the dock which DOES operate in multi-lane mode.


edit:
And I agree. the USB naming standards are deliberately designed by committee to cause confusion - so that OEMs can sell last year's product as "USB 3.2" or whatever with the original spec from USB 3.0.

The names don't just not make sense - they have actually re-named the same spec to a later version with a "gen1" on it.

i.e., if I recall properly, USB 3.2 gen1 is actually the exact same thing as USB 3.0. And USB 3.1 gen1.

Having worked on standards bodies such as these, I can tell you that the naming and feature conventions are abysmal. The standards are written by engineers -- really great engineers -- who are terrible at coming up with marketing names and labeling requirements. This is compounded by manufacturers who won't have "Feature X" available for two years, so they want to use the new name with their existing product.

 

[mr_roboto]

Having worked on standards bodies such as these, I can tell you that the naming and feature conventions are abysmal. The standards are written by engineers -- really great engineers -- who are terrible at coming up with marketing names and labeling requirements. This is compounded by manufacturers who won't have "Feature X" available for two years, so they want to use the new name with their existing product.

Another very real phenomenon is that standards are standards, but getting everything that implements a standard to successfully talk to every other thing isn't always easy.

Most successful standards have wiggle room allowing implementors to make different choices. In principal everyone is supposed to make allowances for the other end of the connection doing anything that's legal, and perhaps even some things that are not, but in practice that doesn't always happen.

How this might apply here: it has long been true that companies making USB peripherals (especially cheaper ones) test exclusively against Windows running on x86. Because of this, some peripherals end up with an unintentional dependence on "the host does things exactly like Intel USB under Windows", rather than the more desirable "the host does things according to the USB spec". (*)

In this case, it's likely that many USB3 10Gbps peripherals have some small issue with how DesignWare USB or Apple's USB driver stack behave during link training and speed negotiation, and thus end up falling back to the baseline 5Gbps x1 speed guaranteed on all USB3 ports. These unexpected behaviors may be fully legal, but that doesn't mean the peripheral accepts them.


* - Since lots of Linux device driver development happens out in the open, over the years I've read so many horror stories about Linux hackers needing to reverse engineer how the Windows USB driver stack interacts with a specific peripheral, then replicate that behavior in the Linux USB stack.

 

[Alameda]

Another very real phenomenon is that standards are standards, but getting everything that implements a standard to successfully talk to every other thing isn't always easy.

Most successful standards have wiggle room allowing implementors to make different choices. In principal everyone is supposed to make allowances for the other end of the connection doing anything that's legal, and perhaps even some things that are not, but in practice that doesn't always happen.

How this might apply here: it has long been true that companies making USB peripherals (especially cheaper ones) test exclusively against Windows running on x86. Because of this, some peripherals end up with an unintentional dependence on "the host does things exactly like Intel USB under Windows", rather than the more desirable "the host does things according to the USB spec". (*)

In this case, it's likely that many USB3 10Gbps peripherals have some small issue with how DesignWare USB or Apple's USB driver stack behave during link training and speed negotiation, and thus end up falling back to the baseline 5Gbps x1 speed guaranteed on all USB3 ports. These unexpected behaviors may be fully legal, but that doesn't mean the peripheral accepts them.


* - Since lots of Linux device driver development happens out in the open, over the years I've read so many horror stories about Linux hackers needing to reverse engineer how the Windows USB driver stack interacts with a specific peripheral, then replicate that behavior in the Linux USB stack.

The devices are supposed to pass a suite of compliance tests. That's why companies such as Granite River Labs exist. But in this case, my guess is the cable, but I don't know for sure.