infinity

As far as I understood it, the script is responsible to get the Trim feature working on the OS. But the usb3.1 to SATA converter itself got the TRIM feature thanks to the firmware update. In my opinion it's the most important that the hardware itself (the cable) supports TRIM in the first place. The other thing is the OS, which is not the responsibility of the USB2SATA adaptor. I mean... the OS issue counts for all the cables and JMS578 as well as all the ASM1351. But if the cable won't ever support it, because the manufacturer does decide not to provide a respective firmware (with trim support enabled), then the best OS cannot change anything about this fact. So apparently JMS578 and ASM1351 are good choices. I will give the ASM1351 a shot, as the benchmarks are quite encouraging. Without this script, JMS578 wouldn't have working TRIM either, or not?

Yep, I agree that it actually might make no noticable difference. Though I'd like to maximize the chances to have a good setup. Found this blog here: http://salutepc.altervista.org/ssd-on-usb-3-0-3-1-with-trim-support-windows-linux.html He has almost the same setup as I have (or would like to have): - Samsung 850 EVO - StarTech.com USB312SAT3CB - Windows and probably Ubuntu based Rock64 System He also confirms working Trim and the numbers seem quite solid. So I think that startech thingy looks like a solid choice

Wow, thanks for both hints! Real crap, that they advertise it wrongly as JMS578 based. After doing some research I think I will give the Startech USB312SAT3CB a shot. It is based on a ASM1351 USB3.1 Gen2 controller, which (as some other little reviews show) apparently performs better than JMS578 and it has firmware support as well as Trim support added by a Startech firmware. It's a bit more expensive, but I think I can give it a try and see whether it is okay or not. Perhaps I'll make another order of the ROCK64, then I can directly add their JMS578 based USB3toSATA converter to have it as well.

Thank you very much once again @tkaiser! I'm a bit disappointed by the high consumption and simply hoped that there are alternatives. Sure the additional SATA 3.0 PHY is present and need its power to function, thogh usually an SSD does consume less than 50mW in idle, where I expect an SATA PHY to be present as well on the SSD motherboard. Anyway, your hint about the possibility to upgrade firmware etc. is a real advantage in favour of JMS chips. Any pros and cons for JMS567 vs JMS578 ? I assume I would do nothing wrong bying one like this: ORICO Adapter USB 3.0 zu SATA, USB 3.0 Konverter Kabel für SATA III 2.5 Zoll Festplatte HDD und SSD (claiming to be JMS578 based) By the way: Found this mini review, where the ASMedia chips seem to be way better performance wise: https://superuser.com/questions/1059492/usb3-to-sata-adapter-performance EDIT Apparently ASM1351 does a huge leap in random write performance compared to the others. Perhaps I should go for it and look how it is. I assume UASP is supported by recent/relevant Linux kernels for ASM1351? Would be interesting to see how it performs on a ROCK64 with current 4.4.77 ARMBian nightly.

This is a great review! Quite helpful for me, as I have kind of the same usecase in my mind. The JMS578 power consumption is quite a showstopper. Do you happen to know whether asm1153e or asm1351 may be good alternatives? Looks like these chips do support UASP as well. Perhaps the power consumption would be lower on those? Or does anybody know whether other issues (like missing drivers; no hdparm support etc) might affect the suitability of the ASMedia chips as small USB3 NAS/backup-device usecase?

Thanks @Xaliusand @TonyMac32 @Xalius Speaking about the odroid Adaptor. I read that the rock64 eMMC may be compatible to Odroids eMMC, but cannot find any definitive proof. Now you mention it as well, so may I ask which odroid you refer to? There are, as far as I know, at least two different Odroid eMMCs specifications: one line-up works only with the odroid Cy models (info mentioned on product page). And the other only with Odroid Xy and Uy models. May I ask which odroid you own?

I wonder how you guys write to eMMC. Is it shipped with an eMMC-to-MicrsoSD adaptor, like the Hardkernel eMMCs? Also I'd like to know whether the board has a heatsink mounted? SOC wise it is comparable to Odroid C2, but all the pictures of ROCK64 are without heatsink, although the SOC is apparently running at 1.5GHz, just like the Odroid C2. Is it perhaps a shrunk process node, thus dissipating less heat (than Odroid C2)?

@tkaiser Damn, thats really impressive! This thingy looks like it is going to bring load of fun for little NAS and server applications. Obviosly not comparable to Synology or similar, but it's also not meant to compete with such devices. Great great, thanks for these tests! It's a shame that pine64 is the only distributor, hence it won't push into the market like Rapsberry and Odroid C2 (in case that LibreELEC support vor ROCK64 will ever come to a usable stage). On the other hand... ROCK64 board seems to initiate software development as a pioneer, so many other manufacturers may come with RK3328 boards then. Just like Odroid C2 started the S905/S905x/S912 boom.

Seeing these USB benchmarks: Is anything known about USB3-Hub support? Since the board has only one USB3 port, It'd be interesting to know what happens if you add an USB3 Hub to connect more than one device. Also wondering what would happen with UAS support if such a hub-setup is possible.

@tkaiser Yep I understood it the way you meant it I was just too lazy to explain that I would buy the 3A for high power and also the usb2barrel adaptor that pine64 offers for being able to use any usb phone charger at home. This way i could also connect any 1A to 2A phone charger that I have at home. Thank you very much!

@tkaiser Thanks for these suggestions! So the 3A psu and an additional usb2barrel adaptor would be a good choice. EDIT I'm just concerned a bit about the quality of the usb2barrel adaptor cable that pine64 sells. In terms of awg standard. I'd perhaps need somewhen to extend it to 2m, which most probably wouldn't work then.

Hi there, since the pre-order is open now, I'm wondering whether somebody has already had a look at the power consumption? I'm asking because I cannot decide between 2GB and 4GB version, since I don't know how significant the increase of power consumption might be to the 4GB version. My intention is to use the board as a seafile 24/7 miniserver with an SSD. Currently a BananaPi does this task. Any thoughts about this would be very appreciated

@tkaiserMan these numbers are absolutely awesome! Thanks for this first test to get an idea of this little piece of gold. I'm really looking forward to it to replace my current banana Pi (gigabit LAN and SATA) as my Seafile Cloud Server. Your thoughts about RAM sound sane. I guess 2GB will be enough for seafile and perhaps NAS altogether. What do you think about the capability to install armhf (instead of aarch64) software? Currently the Seafile server and some other stuff is mostly rpi2/3 compatible, which means it is armhf. I don't see any downside so far compared to aarch64. Ram usage is also lower with 32bit. I guess armhf stuff will be working on ROCK64 as well? In terms of USB3: As usb3 is specified to have a quite high capability of power supply... how would that be taken account by the ROCK64 board design? Any idea what the board might lift? I thought about bying a simple USB3toSATA bridge with UASP support and power a Crucial MX300 256GB without an external power supply (just leaving it away). Such an SSD should not consume too much, so I hope that the Rock64 USB3 port could handle it directly. Does anybody have something to say about the points I mentioned? On Topic: Somehow I totally feel you developers. You want to restrict development to worthy boards, which would also increase the quality of development for those few boards, because work is more focused. On the other hand I see boards like my old banana Pi and I really think that it would've never become what it is and as usable as it is without all your effort (which certainly started without much discussion before). From a user perspective it is a very hard topic that you discuss here. Obviously everybody in the community wants as much as possible. Unfortunately new builds/initial support matures after quite some time and then comes the breakthrough (which - sometimes - cannot be anticipated). Somehow it would also be a shame if nobody would even try to establish some initial support, thus nobody would know what the board is capable of :/. I really don't want to be in your situation to decide how this can be handled in the future. I'm just very thankful and happy that ARMBian was founded some years ago and that it became such a name in the ARM business About the ROCK64: One thing is clear: In my optinion the ROCK64 should be supported, as it combines so many good things. The interest is there, quite a few developers are working on it already, apparently. The more interesting is that two totally independent interest groups (ARMBian=Server/Cli aim and then the LibreELEC=Multimedia) show real interest and have put some effort already into it. This can push it very far and both camps can benefit one another. Really really great to see this!

Lupus! Nice!! Seems to work Well... this implicates that most are affected by this issue (if updated from Armbian <=v5.0), but most don't notice, because they didn't set up a mailer in their system. Thank you very much Lupus