Announcement

Collapse
No announcement yet.

Linux Tests Of The QNINE M.2 NVMe SSD Enclosure To USB-C Adapter

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dwagner
    replied
    Originally posted by kcrudup View Post

    ... so it looks like modifying the SCSI generic provisioning mode as detailed in that article (thanks for that) allows "blkdiscard" to work, at least. It's going to take a while to find out if "fstrim" works, as I'd accidentally run "blkdiscard" on my whole device and apparently blew away the filesystem
    Sorry to hear about your "blkdiscard"-mishap - at least I cautiously only suggested to try "fstrim" :-)

    So first, thanks again for the information, I bought myself a piece of the enclosure you linked to, mostly only so I can compare it to my Icy Box with JMicron chip.
    From my experiments so far, both enclosures worked equally well for me, but the JMicron based Icy Box came out slightly better, because of (a) its better cooling abilities, and (b) because the JMicron chip is supported by "smartctl" already, so I can get the SMART values from the NVMe bar, which I cannot when it is in the ASM2364 enclosure.

    Regarding the issues where the bus stalls for a while: I have experienced this with both enclosures, but only when using dodgy cables (which, unluckily, there are plenty around). I can even reproduce getting these errors with both enclosures with one particular (short) cable if I plug it in in one direction, and consistently everything works fine when plugging in the cable in the opposite direction. Which of course should not happen with USB-C at all - but it seems to be all cable-related trouble.

    Regarding speed, the ASM2364 seems to have a very tiny edge over the JMicron chip, but not reallly enough to make a difference.

    "fstrim" worked fine with both using "unmap" mode.

    Leave a comment:


  • kcrudup
    replied
    Originally posted by dwagner View Post
    Can you also say whether "fstrim" works well with this enclosure?
    ... so it looks like modifying the SCSI generic provisioning mode as detailed in that article (thanks for that) allows "blkdiscard" to work, at least. It's going to take a while to find out if "fstrim" works, as I'd accidentally run "blkdiscard" on my whole device and apparently blew away the filesystem
    Last edited by kcrudup; 03-08-2020, 06:36 PM.

    Leave a comment:


  • dwagner
    replied
    Originally posted by kcrudup View Post
    (I understand this thread is nearly a year old, but this is the only such discussion on Phoronix, and hope this helps someone)

    One of the ones I'd tested, an adaptor from UGReen (https://www.amazon.com/gp/product/B07NPFV21K) has the ASM2364 chipset (174c:2362) and it's worked beautifully- no errors of any kind and excellent speeds (as Michael had shown in his testing, it's near-wire speeds).
    Thanks for this info - good to know there now is an alternative.
    Can you also say whether "fstrim" works well with this enclosure? (See also: https://wiki.archlinux.org/index.php...h_TRIM_support )

    Leave a comment:


  • kcrudup
    replied
    (I understand this thread is nearly a year old, but this is the only such discussion on Phoronix, and hope this helps someone)

    Originally posted by dwagner View Post
    You don't really have to guess, since [the JMicron JMS583] is currently the only NVMe <-> USB 3.1gen2 chip on the market. German c't magazine recently tested two such external enclosures ... with similar results: The connection is simply unstable with all enclosures using this chip, and not only under Linux.
    I had the same experience- I'd bought a few USB-C/NVMe adaptors from Amazon, and every one with a JMicron chipset would fail under heavy load- UASP is a multi-queue format, and any time I'd do anything that stressed the writes ("e2fsck", "compact partition" under VMware, etc.) the chipset would lose it and the Linux (5.5.-rcx) USB layer would have to reset the USB and dequeue all the queued requests. It would recover without going offline, but all I/O would pause for 5-20 seconds. It had to have been power related, as I didn't see this when it was plugged into the USB-C Gen2 port on my Thunderbolt dock (which has an 85W PS) and it worked well then, so I'll use it there exclusively when migrating NVMe drives)

    I guess we'll have to wait for the ASMedia ASM2364 chip to hit the market before expecting different results.
    One of the ones I'd tested, an adaptor from UGReen (https://www.amazon.com/gp/product/B07NPFV21K) has the ASM2364 chipset (174c:2362) and it's worked beautifully- no errors of any kind and excellent speeds (as Michael had shown in his testing, it's near-wire speeds). I've moved my VMWare .vmdks onto it now.

    BTW, curiously enough there was a new controller type, the Realtek RTL9210 that I'd heard was supposed to be good, too- but it suffered from the same issues as the JMicron controller, and would get reset by the USB when the queue depth got too high. This, too must have been power related, as it also didn't do it when connected to my TB dock.

    Thankfully Amazon has a generous return policy.



    Leave a comment:


  • starshipeleven
    replied
    Originally posted by torsionbar28 View Post
    McDonalds restaurants are widespread. Widespread != good. Some folks prefer 'good'. For everyone else, there's the dollar menu.
    Don't shift the goalposts.
    The point was "Firewire was not widespread", and "most pro audio/video equipment" is still a niche so even if Firewire did rule in this niche (I was there so I remember it did), you can't say it's widespread.

    Also don't try to make Firewire look like a fine choice for fine people, it was used only because it was faster.
    Most of its very cool features have always been irrelevant (I'm probably the only one left that actually knows what you could do with it, daisy-chaining, devices writing and reading independently on other devices in the daisy chain, sharing a network through devices in the chain, and others).
    That's why it basically stopped being developed as soon as eSata appeared, and dropped entirely as soon as USB finally catched up.

    Leave a comment:


  • torsionbar28
    replied
    Originally posted by starshipeleven View Post
    That's... not really widespread use in any way.
    McDonalds restaurants are widespread. Widespread != good. Some folks prefer 'good'. For everyone else, there's the dollar menu.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by torsionbar28 View Post
    RS232 devices do not require drivers. Their simplicity is why they are still in use today. Baud, data bits, parity, and stop are the only parameters. Not that you ever have to change them, as nearly everything uses 8/N/1.
    Fuck serial connections. Every single piece of shit industrial automation or high end businness device using a "serial" connection is NEVER EVER using a plain 232 but always some form of 232-alike stuff where they rewire the connector and place resistors between lines, and require random funky settings on speed and stuff, just because they can. Fuck them with a chainsaw.

    USB on the other hand, was a complicated cumbersome mess, where every device requires a driver,
    Yes. And this forces the manufacturer to actually deal with their shit on their own, so I don't have to set up shop and splice wires all the time. Any USB device has been painless on my side.

    Windows users call this "driver hell".
    Never heard the term, and I'm in IT since 2 decades at least.

    Remember when Bill Gates did a live demo of Windows 95? He plugged in a USB device and the whole OS crashed with BSOD, for the world to see. No such problems with RS232 serial.
    No such problem with punched cards or magnetic tape either, not a good argument for either.

    Incorrect, most pro audio/video equipment was firewire only.
    That's... not really widespread use in any way.

    When you have large audio and video data to move around, USB2 was simply too slow.
    maybe you don't know of its existence if you were in the Apple camp, but eSata was a thing for plebs and was common enough up and until USB 3.0 appeared. Also was Sata so SMART did work fine also on Linux 100% of the times.

    Laptops had some EsataP ports https://en.wikipedia.org/wiki/ESATAp with combined esata and power for an external drive.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by torsionbar28 View Post
    USB 3.1 uses UASP for storage, so full SCSI command set is available. USB prior to 3.1 was junk, with junk protocols and implementations that were hit or miss on SMART. USB 3.1 fixes this mess finally.
    I have quite a few sata drive boxes that support UASP but still don't show a damn thing on SMART on Linux (while everything works on Windows), so I'm unsure of what you are saying here.

    Leave a comment:


  • torsionbar28
    replied
    Originally posted by PCJohn View Post
    I might be mistaken on this point, but how would you connect a printer?
    We've strayed way off course now, if you review my original post, you'll see I was criticizing USB when used for storage devices. USB is perfectly suitable for low bandwidth devices like keyboards, mice, printers, etc. and I have no problems with it in this usage. This was after all, its intended purpose when it was first invented. But prior to USB 3.1, myself and many others have found USB to be entirely unsuitable for use with external bulk storage devices.[/QUOTE]

    Leave a comment:


  • PCJohn
    replied
    Originally posted by torsionbar28 View Post
    Sounds like you're confused here. RS232 devices do not require drivers.
    I might be mistaken on this point, but how would you connect a printer? You need to install printer driver and setup port which the printer driver needs to use. But I might be mistaken here. I am happy that companies joined together and created standards, replacing whatever computer ports by some standard. Plug-and-play seemed a good idea to me even although it used to be called plug-and-pray. But for me it was right way to go. But I do not mind if FireWire would become widely used standard instead of USB.

    Originally posted by torsionbar28 View Post
    Their simplicity is why they are still in use today. Baud, data bits, parity, and stop are the only parameters. Not that you ever have to change them, as nearly everything uses 8/N/1. USB on the other hand, was a complicated cumbersome mess, where every device requires a driver, Windows users call this "driver hell". Remember when Bill Gates did a live demo of Windows 95? He plugged in a USB device and the whole OS crashed with BSOD, for the world to see. No such problems with RS232 serial. BTW my first PC was a Compaq 286 with 1200 baud modem...
    Feel free to like RS232, it is really simple from the signal point of view and if it works, it works. I still use one parallel port and it is just a pain. USB is a dream of heaven compared to my parallel port. My future is only any plug-and-play technology. A device should identify itself to the OS. This way, driver installation is much simplified. I would not like to go back. Driver-hell is probably not hell for me. I suffer by DLL-hell only. Surely, I accept that bad driver easily crashes OS, like it happened to Bill Gates. And no application or OS is bug free. But situation improved much. My first PC was 286 with two serial and one parallel port while I had hands on IBM-XT before.

    Originally posted by torsionbar28 View Post
    Incorrect, most pro audio/video equipment was firewire only. Because USB 2.0 was so crappy and slow, high bandwidth devices all came in Firewire versions, for people who care about performance.
    Oh, now I see where you came from. I was wondering why somebody might use so strong words against USB 2.0. Majority of us who are not audio/video would probably not call USB 2.0 crappy. Personally, I am also transfer-hungry (100GiB/s), but it is not towards external devices.

    Leave a comment:

Working...
X