Home of the Squeezebox™ & Transporter® network music players.
Page 6 of 11 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 104
  1. #51
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,149
    Thanks Ronnie - I'll have a read.

  2. #52
    Senior Member paul-'s Avatar
    Join Date
    Jan 2013
    Posts
    4,589
    You are missing information to determine if UASP is used/supported

    1 - Check to see how it is detected.
    Code:
    tc@Pi4-aarch64-Devel:/mnt/build/aarch64$ lsusb
    Bus 002 Device 003: ID 04e8:4001 Samsung Electronics Co., Ltd    <<------- this is my SSD, sitting on Bus 002, Device 003
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 005: ID 1a86:e050 QinHeng Electronics
    Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. 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
    
    tc@Pi4-aarch64-Devel:/mnt/build/aarch64$ lsusb -t
    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
        |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M                  <<---Bus2, Port 3 is shown using the uas driver.
    /:  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
            |__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
                |__ Port 1: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
                |__ Port 1: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 12M
                |__ Port 1: Dev 5, If 2, Class=Human Interface Device, Driver=usbhid, 12M
                |__ Port 1: Dev 5, If 3, Class=Human Interface Device, Driver=usbhid, 12M
    2 - To examine the drive capabilities
    Code:
    tc@Pi4-aarch64-Devel:/mnt/build/aarch64$ lsusb -v -d 04e8:4001 | grep -i interface    <<-----enter the xxxx:xxxx device identifier shown from lsusb
      bDeviceClass            0 (Defined at Interface level)
        bNumInterfaces          1
        Interface Descriptor:
          bInterfaceNumber        0
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     80 Bulk-Only
          iInterface              0
        Interface Descriptor:
          bInterfaceNumber        0
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     98                       <<------ Interface Protocol 98 means the device supports UASP
          iInterface              0
    piCorePlayer a small player for the Raspberry Pi in RAM.
    Homepage: https://www.picoreplayer.org

    Please donate if you like the piCorePlayer

  3. #53
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,149
    Thanks again Paul. So it appears that the M.2 drive is using UAS after all:

    Code:
    tc@pCPServer:/usr/local/bin$ ./lsusb
    Bus 002 Device 003: 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 bridge
    Bus 002 Device 002: ID 0781:5583 SanDisk Corp. Ultra Fit
    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
    
    tc@pCPServer:/usr/local/bin$ ./lsusb -t
    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
        |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
        |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 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
    
    tc@pCPServer:/usr/local/bin$ ./lsusb -v -d 174c:55aa | grep -i interface
      bDeviceClass            0 (Defined at Interface level)
        bNumInterfaces          1
        Interface Descriptor:
          bInterfaceNumber        0
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     80 Bulk-Only
          iInterface              0 
        Interface Descriptor:
          bInterfaceNumber        0
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     98 
          iInterface              0
    Maybe this explains why it is 50% faster than the previous SATA SSD - I'll have to go back and recheck that one.

    I did load the full Raspberry Pi OS onto a spare SD card and I got the same '[Unmap command not implemented]'. SO I starting to doubt what the Western Digital Dashboard told me about Trim under Windows - I'll take another look.

  4. #54
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,149
    Quote Originally Posted by chill View Post
    Maybe this explains why it is 50% faster than the previous SATA SSD
    It doesn't. Both drives show up as identical devices with identical IDs (is that possible?), and both are using the uas driver.

    Code:
    tc@pCPServer:/usr/local/bin$ ./lsusb
    Bus 002 Device 003: 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 bridge
    Bus 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 bridge
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 003: ID 0781:5583 SanDisk Corp. Ultra Fit
    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    
    tc@pCPServer:/usr/local/bin$ ./lsusb -t
    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
        |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
        |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 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
            |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    
    tc@pCPServer:/usr/local/bin$ ./lsusb -v -d 174c:55aa | grep -i interface
      bDeviceClass            0 (Defined at Interface level)
        bNumInterfaces          1
        Interface Descriptor:
          bInterfaceNumber        0
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     80 Bulk-Only
          iInterface              0 
        Interface Descriptor:
          bInterfaceNumber        0
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     98 
          iInterface              0 
      bDeviceClass            0 (Defined at Interface level)
        bNumInterfaces          1
        Interface Descriptor:
          bInterfaceNumber        0
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     80 Bulk-Only
          iInterface              0 
        Interface Descriptor:
          bInterfaceNumber        0
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     98 
          iInterface              0
    So given that unmap is supported by the old Sandisk SATA drive on what appears to be the same adapter, the fact that it's not supported on the new Western Digital M.2 SATA drive is unlikely to be the fault of the adapter.

  5. #55
    Senior Member paul-'s Avatar
    Join Date
    Jan 2013
    Posts
    4,589
    If you read the threads, the Asmedia adapters are going to be dependent on the firmware loaded on the adapter.

    It doesn't surprise me that the M.2 drive is faster though...
    piCorePlayer a small player for the Raspberry Pi in RAM.
    Homepage: https://www.picoreplayer.org

    Please donate if you like the piCorePlayer

  6. #56
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,149
    Quote Originally Posted by paul- View Post
    If you read the threads, the Asmedia adapters are going to be dependent on the firmware loaded on the adapter.
    This seems to be the key. I downloaded the 141126_A1_EE_82 firmware (from here), and the zip file includes a Windows executable to flash the firmware. The executable also tells you what version is already on the device.

    It told me that the old SATA adapter (which supports trim with my Sandisk SATA SSD) is (was*) at firmware 141126_A1_EE_83, whereas my new Argon 40 M.2 SSD adapter was as 140704_A1_00_00. If the lower number corresponds to an earlier version, it seemed possible that an update to a higher number might enable trim.

    So I took a brave pill and decided that if I bricked the adapter then I'm only out ú18. I updated the M.2 adapter to 141126_A1_EE_82. (Note that the update will FAIL if there's a disk drive attached - this is what I tried first, because detaching the drive requires a small amount of disassembly, and I was being lazy).

    Now when I inspect the adapter+drive as before under pCP I see:

    Code:
    tc@pCPServer:/mnt/sdb2/tce$ sg_vpd -p lbpv /dev/sda | grep Unmap
      Unmap command supported (LBPU): 1
    
    and
    
    tc@pCPServer:/mnt/sdb2/tce$ sg_vpd -p bl /dev/sda | grep unmap
      Maximum unmap LBA count: 4194240
      Maximum unmap block descriptor count: 1
      Optimal unmap granularity: 1 blocks
    So now it looks as though the adapter supports trim and I can press on and enable it. It's odd that the Argon M.2 adapter, which I purchased ~18 months after the old SATA adapter, should have an apparently older firmware. I hope the update hasn't broken anything else, because I can't find the 140704_A1_00_00 version to revert it.

    *I 'accidentally' loaded the 82 firmware over the 83 version that was already on my old SATA adapter, so now of course I'm worried what feature was added/fixed in that single digit increment!

  7. #57
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,149
    Success! With the 'unmap' provisioning mode made persistent by following Paul's guidance for editing bootlocal.sh, I can now issue the fstrim command after a reboot.

    Code:
    tc@pCPServer:~$ sudo fstrim -v /mnt/Music
    /mnt/Music: 45572067328 bytes trimmed
    Just need to set up the cron job now.

    That figure of 45572067328 bytes seems to be exactly equal to the amount of free space on the drive.

  8. #58
    Senior Member paul-'s Avatar
    Join Date
    Jan 2013
    Posts
    4,589
    That first large unmap will happen only the first run after boot. After that it will only be the bytes that have changed since the last unmap.

    So I would run a trim even (in the background) shortly after booting your device. Then on a weekly cron job.
    piCorePlayer a small player for the Raspberry Pi in RAM.
    Homepage: https://www.picoreplayer.org

    Please donate if you like the piCorePlayer

  9. #59
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,149
    Quote Originally Posted by paul- View Post
    So I would run a trim even (in the background) shortly after booting your device. Then on a weekly cron job.
    Thanks Paul - that's how I've set it up, and yes, if I run the command a second time, it returns 0 bytes.

    But wait - I don't recommend updating to the firmware that I've used for the moment. The read and write speeds seem to have dropped to the same as the older SATA adapter+drive, i.e. the 50% boost has gone, despite still using UAS. Something else must have changed!

  10. #60
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,149
    I was able to find (from here) and reload the original 140704_A1_00_00 firmware for the Argon M.2 adapter, but it did not restore the original speed. It simply removed the trim support. I tried it also on a fresh pCP7 install, in case anything about enabling trim had caused the slow down, but no joy.

    So this makes me think that the original speed improvement was a function of some configuration option in the firmware, rather than the firmware capability itself, which gives me hope that a bit more experimentation might bring that back under the trim-capable firmware. But if it doesn't, well I'm happy that the current speeds (write speed ~150MB/s and read speed ~210MB/s), equivalent to my previous SATA SSD, are more than enough for a mostly static LMS music library, and that the added trim support will extend the life of the drive.

    So I've put the newest available firmware (141126_A1_EE_82) back on, which has restored trim support.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •