10

I have a Pi 4B (with latest firmware upgrade) running Raspbian Buster and a 2TB SSD with a SATA 3 interface. I'm using a SATA 3 to USB 3 converter that can also connect to external power when necessary.

The SATA 3 to USB 3 converter works fine: I have tested it on an Ubuntu 18.04 desktop PC. When I run sudo hdparm -t --direct ... I get a decent 290 MB/s , even without external power.

On the Pi 4B, even with external power, I get at most 1.3 MB/s !!! Am I missing something here ?

  • SSD model: SAMSUNG, 860 QVO 2 To 2.5'' SATA III (6 Gb/s)
  • SATA to USB-3 converter: Bluestork super speed box 2'5
ma3oun
  • 273
  • 1
  • 3
  • 8

4 Answers4

14

Sometimes the actual official Raspberry Pi Foundation forum, among whose members are RPi Foundation staffers, is worth a visit. There is an issue affecting the Raspberry Pi 4 and certain USB devices.

How to tell if your drive is affected, and what to do about it:

STICKY: If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this ...

We have seen reports of extremely degraded performance when using several types of USB3.0 to SSD adapter or when using native USB3.0 disk drives. This post details why there is a difference in behaviour from models prior to Pi 4 and the recommended workaround.

Link to sticky at raspberrypi.org

Michael Harvey
  • 1,390
  • 7
  • 11
  • Thanks for the link but I'm not satisfied with the given explanation as it points to "faulty" UAS implementation in the converter. How is it then that the converter works fine on a desktop PC with Ubuntu ? – ma3oun Aug 06 '19 at 20:23
  • Why don't you try the workaround? Maybe the x86 Ubuntu has more compatible UAS driver? Please try the suggested workaround and let us know the result. – Michael Harvey Aug 06 '19 at 20:25
  • 2
    "I'm not satisfied with the given explanation" - if the workaround improves your speed, then satisfied or not, it would seem to be a correct explanation, don't you think? – Jaromanda X Aug 06 '19 at 22:58
  • 2
    It works indeed. To be honest, I think that people at the RPI foundation don't want to admit they haven't done a great job with USB on the RPI4: faulty usb-C power management and faulty handling of UAS on the USB 3 ports... – ma3oun Aug 07 '19 at 05:49
  • @ma3oun "How is it then that the converter works fine on a desktop PC with Ubuntu?" - do you have UAS enabled there? – Dmitry Grigoryev Sep 27 '19 at 12:54
  • 1
    @DmitryGrigoryev : Yes, I've checked the used driver and it's UAS. – ma3oun Sep 27 '19 at 13:19
  • 1
    I checked the driver used by my SSD – ma3oun Sep 27 '19 at 14:35
3

check out https://jamesachambers.com/new-raspberry-pi-4-bootloader-usb-network-boot-guide/ .. i had the same issues but after applying quirks. I copy pasted that part here below.

Fix (some) USB Adapter Problems Using Quirks

Some of the very common adapters on the naughty list above (such as the Sabrent) can be made to work by using USB quirks to disable UAS mode on the drive. This lowers performance, but it’s still much faster than a SD card and your adapter won’t go to waste.

To find out the quirks we need to find the device ID string for your adapter and then add an entry to cmdline.txt telling the kernel to apply them on boot.

Find Your Adapter

To apply the quirks we first need to get the adapter id. We will use the sudo lsusb command:

$ sudo lsusb
 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

On line 2 we can see my ASM1051E SATA 6Gb/s bridge adapter (it’s the known working StarTech.com 2.5″ SATA to USB adapter). You will see something very similar to mine when you run the command and it shouldn’t be too hard to figure out which device it is. If you need more information add a -v switch to make the command sudo lsusb -v. This can sometimes add some additional details to make it easier to figure out which one is your adapter.

If you’re still not sure, we have another command that between the two that can narrow things down. Type / paste the following:

sudo dmesg | grep usb

[    0.828535] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
 [    0.828568] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 [    0.828597] usb usb3: Product: DWC OTG Controller
 [    0.828620] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd
 [    0.828644] usb usb3: SerialNumber: fe980000.usb
 [    0.830051] usbcore: registered new interface driver uas
 [    0.830182] usbcore: registered new interface driver usb-storage
 [    0.836488] usbcore: registered new interface driver usbhid
 [    0.836511] usbhid: USB HID core driver
 [    0.971598] usb 1-1: new high-speed USB device number 2 using xhci_hcd
 [    1.154217] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
 [    1.154254] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
 [    1.154281] usb 1-1: Product: USB2.0 Hub
 [    1.301989] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
 [    1.332965] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
 [    1.332999] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 [    1.333026] usb 2-1: Product: ASM105x
 [    1.333048] usb 2-1: Manufacturer: ASMT
 [    1.333071] usb 2-1: SerialNumber: 123456789B79F

This is the dmesg log showing the hardware detection as hardware is activated on the Pi. If your log is really long you can generate fresh entries by just unplugging a device and plugging it back in and running the command again. Here we can clearly see that the ASM105x is what our StarTech adapter is being detected as.

Now we can go back to our first lsusb command and we want the 8 characters from the ID field that comes right after the Device:

Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge
Our adapter’s ID is: 174c:55aa

Applying Quirks

To apply the quirks to our USB adapter we are going to edit /boot/cmdline.txt.

Type:

sudo nano /boot/cmdline.txt

We are going to add the following entry into the very front of cmdline.txt:

usb-storage.quirks=XXXX:XXXX:u

In place of the X’s above you will put in your adapter’s ID that we got before. With the example commands I gave above mine would look like this: usb-storage.quirks=174c:55aa:u. After this my cmdline.txt looks like this (everything should be one continuous line, no line breaks!):

usb-storage.quirks=174c:55aa:u console=serial0,115200 console=tty1 root=PARTUUID=d34db33f-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Now reboot the Pi. If the Pi fails to boot you can plug the SD card into the computer and go to /boot/cmdline.txt and undo the change we did so you can boot back in with your SD card.

Verifying Quirks

Once you have rebooted after changing cmdline.txt we can verify the quirks have been applied by doing another dmesg | grep usb command:

sudo dmesg | grep usb
 [    1.332924] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
 [    1.332957] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 [    1.332983] usb 2-1: Product: ASM105x
 [    1.333006] usb 2-1: Manufacturer: ASMT
 [    1.333028] usb 2-1: SerialNumber: 123456789B79F
 [    1.335967] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
 [    1.336071] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
 [    1.336103] usb-storage 2-1:1.0: USB Mass Storage device detected
 [    1.336479] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
 [    1.336611] scsi host0: usb-storage 2-1:1.0
Mats Karlsson
  • 983
  • 5
  • 11
Marcel Hofstra
  • 31
  • 1
0

Without knowing all the technical details of the situation, I have been made aware that the USB hardware on the pi 4 doesn't like some cables. One youtuber tried about half a dozen different cables to various SSDs. (They did the same thing with power cables, btw). Not all the usb to ssd cables worked, to the pi 4, even if they worked on other computers. I regret that I do not recall which out of many youtubes and blogs detailed this. But the approach was summarized to the simple, "try a few different brand cables". One youtuber went further and modified the USB end of the cable and got it to work in some situations with some SSDs.

Personally, although I like to know exactly what is going on, so I can contribute the detail(s) with confidence to others, another part of me is becoming more easily content with knowing "brand x cable is problematic, while brand y cable has not manifested the same problem, and brand z might work with some drives if you modify the usb end wiring.". Back in the days when Apple was using SCSI drives and chains, that could become a wild ride matching and arranging proper cables and active or passive terminators to keep everything humming and showing up properly on a moderate to long SCSI chain. It wasn't an Apple problem, but an issue that manifested with cables, terminators, device combinations, and depending on the EMI environment. It was not a simple SCSI ID issue, although those days certainly did give rise to the popularity of the SCSI_probe tool(s). SCSI was fast in those pre-USB3 and Firewire etc days.

If anyone has encountered a cable as a solution, with a Pi 4 and an SSD, please say so, and the SSD brand/model and cable that worked. It could prove to be helpful, not to slam a cable or device manufacturer, but to understand that such issues can manifest when any piece in the hardware picture is not quite following quite the same 'spec' -- fully, or, is the victim of some unique EMI or power environment.

Thinking simple first, a cable swap is relatively painless,with all power off of course, and properly spec'd. And inspect and be careful with those cable connectors and contacts.

always_learning
  • 339
  • 2
  • 13
0

I got a similar problem using an SSD M2 disk with an USB3 adapter. Using the original cable I had a lot of error in dmesg and the speed is about 8 MB/s! I tried another cable (heavier than the original, it was for an external 2.5'' disk) and the problem vanished. Last test via hdparm gave me 300 MB/s. If you can, try another cable. I believe, but need further investigation, the USB3 port of raspiPi4 are a bit more fussy than the regular pc ones, or the problem is the power the port

T. Binda
  • 1