Argon ONE NVMe Board (maybe) Slower than SATA - Martin Rowan (2024)

I really like the products produced by Argon40, even if there have been a number of issues along the way. When I saw they had released an expansion board with NVMe support I decided to buy one to test it out. At present, the Argon ONE NVMe expansion board is only available as a standalone board to extend the Argon ONE platform, the M.2 SATA version is available as either an expansion board or bundled with an Argon ONE v2.

TLDR

18 Feb 2023: Please see the updated post following new firmware from Argon Forty: Argon ONE NVMe Board – Fixed!

Unfortunately, I’m unable to find an upside to the Argon ONE NVMe expansion board. The power consumption is higher and the storage performance is significantly slower, despite the claim that from ASMedia – “Support BOT and UAS Protocol” and Argon40 – “Argon ONE M.2 is UASP Supported for the Raspberry Pi 4 which means you can maximize the transfer speeds of your M.2 NVME Drive.” my testing has shown that the board doesn’t use UAS Protocol, resulting in unexpectedly poor performance. The reason it doesn’t use UAS is that the board USB descriptors aren’t advertising that it supports it, it’s only advertising it as a bulk storage device which means the UAS Protocol can’t be used.

9th Jan 2023: Argon40 have been contacted for comment on this issue and I’ll post a follow-up if I obtain more information or a solution. Hopefully, the firmware can be updated and address boards that have already been shipped.

11th Jan 2023: The Chinese new year holidays will impact the discussions with the Argon40 team. In the meantime, I’ve ordered another board from another supplier and I’ve also asked via Twitter for some other users to check if their boards are using UASP or not. One response appears to show it is, but also that the board has a vid/pid, so may be a firmware issue with the board I have. Some users on the Argon40 community forum also appear to have the board using the usb-storage driver instead of uas. For now, I’ve amended the title of this post, to add a degree of uncertainty to my findings.

12th Jan 2023: A second NVMe Expansion board arrived from Pimoroni, my 1st board was from ThePiHut. Hooking the new board up and it has the same vid and pid, and uses usb-storage not uas driver. I found some firmware for the ASM2362 and following this video guide backed up the original firmware and installed the new firmware, this resolved the problem. I’m in touch with Argon40, but due to the new year holiday investigation into how boards with the wrong firmware got out into the channel will remain on hold.

Storage Performance

NVMe storage is intended to be directly attached to the PCIe bus, with at least x4 PCIe lanes to provide the throughput the technology is capable of. The Raspberry Pi 4’s USB 3.0 ports support data rates of 5 Gbit/s (500 MB/s after encoding overhead) are going to be the limiting factor and I know I’m not going to get close to the 3300MB/s read speed of the WD Blue SN570 NVMe drive. In fact, the SATA drive performance is around the same as the maximum data rates for USB 3.0, so really there isn’t any apparent benefit from using NVMe over SATA, except that you may have some NVMe drives lying around that you might want to use on your Raspberry Pi project.

Testing Methodology

I’ve used a benchmarking script provided by Jeff Geerling to perform the testing which uses fio and iozone to measure the performance for 1MB sequential reads, 1MB random reads and writes and 4k random reads and writes. Each scenario was repeated 3 times and the results averaged.

The Raspberry Pi 32bit desktop image (2022-09-22, with latest updates as of 8th Jan 2023) was used, installed initially to an SD Card and then replicated to the other storage types using the built-in SD Card copier.

Whilst testing with other storage, the MicroSD card is removed to avoid any chance of accidentally testing the wrong storage.

See Also

Argon ONE NVMe Board - Fixed! - Martin Rowan

Devices under test:

• MicroSD Card – SanDisk Max Endurance 32GB
• M.2 SSD – Kingston SA400M8/240GB
• NVMe – WD Blue SN570 250GB
  • Argon ONE NVMe Expansion board
  • Sabrent USB NVMe enclosure

Storage Performance Results

It’s clear that opting for SSD or NVMe storage provides significantly higher storage throughput than a MicroSD card. However, the performance of the Argon NVMe expansion board is lower than the Argon SSD board:

• iozone 4k random write: Argon ONE SSD 61% higher than Argon ONE NVMe
• iozone 4k random read: Argon ONE SSD 32% higher than Argon ONE NVMe
• iozone 1M random write: Argon ONE SSD 27% higher than Argon ONE NVMe
• iozone 1M random read: Argon ONE SSD 13.6% higher than Argon ONE NVMe
• fio 1M sequential read: Argon ONE SSD 137% higher than Argon ONE NVMe

Switching the same WD Blue NVMe drive from the Argon ONE NVMe enclosure into a Sabrent USB enclosure shows the performance of the NVMe much closer to the SSD, outperforming the SSD by a small margin in several of the tests:

• iozone 4k random write: USB NVMe 0.6% higher Argon ONE SATA
• iozone 4k random read: USB NVMe 13% higher Argon ONE SATA
• iozone 1M random write: USB NVMe 3.9% higher Argon ONE SATA
• iozone 1M random read: USB NVMe 8.6% higher Argon ONE SATA
• fio 1M sequential read: USB NVMe 3.7% lower Argon ONE SATA

Further investigation into the poor performance of the Argon ONE NVMe enclosure follows.

Power Consumption

The SSD and NVMe storage both have significantly higher power usage at idle and in use when compared to the MicroSD. The NVMe solutions have the highest power consumption. Given there doesn’t appear to be a performance gain, due to the USB 3.0 limitations, there doesn’t appear to be a compelling case for considering an NVMe drive.

Argon ONE NVMe Power

Based on information from Sabrent, an SSD typically has a maximum power requirement of less than 4W, whereas NVMe will be between 3.5 and 8.5W. This increased power demand may be too much for what the Raspberry Pi 4 can deliver from its USB ports. Especially as the total available power from the Raspberry Pi 4 USB ports is shared between all ports and limited to 1.2A (~6W). Argon40 have addressed this by the addition of a pogo pin on the Argon ONE NVMe expansion board which contacts with a test point TP2 on the underside of the Raspberry Pi 4 PCB, which in turn is connected to Vcc (5 Volts). Thus allowing the Argon ONE NVMe board to be powered without the power limitations of the USB interface.

Update 27 Feb 2023: It appears later versions of the SATA board also have this pogo pin to provide extra power, per this forum post.

Investigating NVMe Storage Performance Anomaly

Initial checks show that the ASM2362controller is detected as an ASM1051E/ASM1053E/ASM1153/ASM1153E SATA bridge which looks wrong, the ASM2362 isn’t a SATA bridge, it’s a USB to PCI Express bridge. Early version of the Argon SATA controller board (v1.6) use the ASM1153E and later versions (v2.2) use ASM235CM both SATA bridge solutions.

pi@storage-test2:~ $ lsusbBus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridgeBus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hubBus 001 Device 002: ID 2109:3431 VIA Labs, Inc. HubBus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubpi@storage-test2:~ $ lsusb -t/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

Checking the VID and PID for the various devices and Argon ONE boards shows:

The Sabrent USB NVMe uses a JMicron JMS583S which is correctly identified correctly as a PCIe Bridge:

pi@storage-test2:~ $ lsusb -tv/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M ID 1d6b:0003 Linux Foundation 3.0 root hub |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 Bridge/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M ID 2109:3431 VIA Labs, Inc. Hub

So both the SATA v1.6 and the NVMe board report the same vid and pid although using completely different ASMedia bridge solutions. Both devices also show as being detected as a USB Mass storage device and that “Quirks” have been applied for that given vid/pid.

Recompile the Kernel

Searching the Raspberry Pi kernel source finds 2 potentially important entries, one in unusual_devs.h that sets some “Quirks” based for the devices identified with that pid and vid combination:

/* Reported by Oliver Neukum <[emailprotected]> */UNUSUAL_DEV( 0x174c, 0x55aa, 0x0100, 0x0100,"ASMedia","AS2105",USB_SC_DEVICE, USB_PR_DEVICE, NULL,US_FL_NEEDS_CAP16),

There is also code in uas-detect.h that attempts to specific variants of the ASMedia chips that are all sharing the same pid and vid:

/* * ASMedia has a number of usb3 to sata bridge chips, at the time of * this writing the following versions exist: * ASM1051 - no uas support version * ASM1051 - with broken (*) uas support * ASM1053 - with working uas support, but problems with large xfers * ASM1153 - with working uas support * * Devices with these chips re-use a number of device-ids over the * entire line, so the device-id is useless to determine if we're * dealing with an ASM1051 (which we want to avoid). * * The ASM1153 can be identified by config.MaxPower == 0, * where as the ASM105x models have config.MaxPower == 36. * * Differentiating between the ASM1053 and ASM1051 is trickier, when * connected over USB-3 we can look at the number of streams supported, * ASM1051 supports 32 streams, where as early ASM1053 versions support * 16 streams, newer ASM1053-s also support 32 streams, but have a * different prod-id. * * (*) ASM1051 chips do work with UAS with some disks (with the * US_FL_NO_REPORT_OPCODES quirk), but are broken with other disks */if (le16_to_cpu(udev->descriptor.idVendor) == 0x174c &&(le16_to_cpu(udev->descriptor.idProduct) == 0x5106 || le16_to_cpu(udev->descriptor.idProduct) == 0x55aa)) {if (udev->actconfig->desc.bMaxPower == 0) {/* ASM1153, do nothing */} else if (udev->speed < USB_SPEED_SUPER) {/* No streams info, assume ASM1051 */flags |= US_FL_IGNORE_UAS;} else if (usb_ss_max_streams(&eps[1]->ss_ep_comp) == 32) {/* Possibly an ASM1051, disable uas */flags |= US_FL_IGNORE_UAS;} else {/* ASM1053, these have issues with large transfers */flags |= US_FL_MAX_SECTORS_240;}}

In order to test if this was the problem, I removed the quirks entry and the special handling code in uas-detect.h and recompiled and the kernel. The modified kernel loaded and showed the quirks weren’t being applied, but the device still used the usb-storage driver and not the faster uas driver.

Device Firmware

Researching more about what is required for a device to claim it supports UASP, I found this thread which stated that the device should advertise an Interface Descriptor with “bInterfaceProtocol 98” (in addition to one with “bInterfaceProtocol 80 Bulk-Only”). Checking the output of sudo lsusb -v for the Argon M.2 (v2.2) SATA board and the Argon NVMe board and the Sabrent NVMe USB enclosure showed that both the SATA and Sabrent NVMe listed multiple interface descriptors one with bInterfaceProtocol 80 and another with 98. The Argon ONE NVMe expansion board with the ASM2362 didn’t include the bInterfaceProtocol 98 section.

So it appears that whilst the hardware may be capable of UASP, the current configuration or firmware for the device isn’t configured to have it enabled. As far as I know, there isn’t a way to force enable UASP if the device doesn’t have it enabled.

Below are links to the output from the command: sudo lsusb -v showing the USB descriptors for each of the devices:

• Argon ONE NVMe USB descriptors
• Argon ONE M.2 SATA (v2.2) USB Descriptors
• Sabrent USB NVMe USB Descriptors

Updating ASM2362 Firmware

Section added: 12th January 2023

Following the arrival of a 2nd NVMe expansion board bought from Pimoroni (the 1st from ThePiHut) which exhibited the same issue along with confirmation on EddieSneed on twitter that there are working boards out there with different vid/pid, I concluded that the boards had likely been flashed with the wrong firmware, using the firmware for the M.2 SATA boards using the AS1153E chip. Following this video on YouTube I was able to backup the original firmware supplied, and install new firmware from driver-station.com to test things out.

Note: I used firmware AS_PCIE_210527_81_3A_00.bin the 3A_20.bin version, installed but didn’t appear to expose the storage, I used VID:174c and PID:2362, EddieSneed’s board had Vendor ID of: 199d, but that doesn’t belong to ASMedia, they should use 174c, so I’m not sure Argon40 should be using that. Though the Product ID for the ASM2362 doesn’t appear to be registered either.

With the new firmware, lsusb -tv shows the uas driver in use:

pi@storage-test2:~ $ lsusb -tv/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M ID 1d6b:0003 Linux Foundation 3.0 root hub |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M ID 174c:2362 ASMedia Technology Inc./: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M ID 2109:3431 VIA Labs, Inc. Hub

The full set of USB Descriptors with the new firmware can be found here. The key is that it does include the missing bInterfaceProtocol 98 interface section. However, it doesn’t appear that trim is supported. I’m not going to investigate that further until I get official firmware from Argon40.

As this isn’t official firmware, I’m not going to update all the published benchmark results, but to show demonstrate the difference:

Conclusion

If you’re considering the Argon ONE NVMe expansion board, I’d suggest you hold off until this issue is resolved or instead get the M.2 SATA version. Though it appears ASMedia or Argon40 aren’t making it easy for kernel/driver developers to identify a wide range of their chips which have various issues and capabilities that need special handling. So even if you have hardware that should support UAS there is a chance the code in the driver today may force it to use the usb-storage driver instead. So best to check.

I’m beginning to wonder if they’ve just flashed the wrong firmware on these boards, given the reused vid/pid and incorrect description of the device.

12th Jan 2023: I’ve pretty much confirmed this is what has happened. Awaiting a response after the Chinese New Year holiday on how they plan to address this.

Hopefully, Argon40 can release some means of updating the firmware on these boards, and not require a hardware respin to address this issue.

Product Links

• Argon ONE V2 Raspberry Pi 4 case (Amazon) (ThePiHut)
• Argon ONE M.2 SATA Raspberry Pi case (Amazon) (ThePiHut)
• Argon ONE M.2 SATA Expansion board (Amazon) (ThePiHut)
• Argon ONE NVME Expansion board (ThePiHut) (Pimoroni)
• Western Digitial Blue SN570 M.2 NVMe 250GB (Amazon)
• Sabrent USB 3.2 NVMe Enclosure (Amazon)
• SanDisk Max Endurance 32GB (Amazon)

Amazon links are affiliate links which help support the site, where possible I’ve used links which should take you to the product in the Amazon store in your region. Links to other suppliers are included for your convenience.