tkaiser Posted July 6, 2017 Posted July 6, 2017 New try with latest ayufan OMV build (after fixing some issues like rrdcached doing stupid things on all 4 cores or IRQ affinity settings not working and so on). Performance governor, EVO 840 120GB (cheap consumer crap), UAS/JMS567. Test with 100 MB and 12 GB (only testing with 4K and 16M blocksizes and sequential transfer speeds only: Samsung EVO 840 (slowest 120 GB model, small TurboWrite buffer) with UAS: random random kB reclen write rewrite read reread read write 102400 4 15325 20806 22007 22979 16980 21169 102400 16 52930 77415 69738 77945 63361 67742 102400 512 287901 316528 305584 289701 279577 264499 102400 1024 314457 343568 333184 344791 336613 350049 102400 16384 359641 363954 359817 374210 374654 364461 12288000 4 17466 21834 24245 24389 12288000 16384 118447 134973 368548 368181 The 120GB EVO 840 is a bad choice for performance tests since rather slow and bottlenecked by a pretty small 'TurboWrite buffer'. Like all cheap consumer SSDs this one shows dramatically dropping write performance if amount of data exceeds the size of the TW buffer (IIRC just 1 GB on this model). That explains why write performance with 12GB test size is that low. But looking at the above numbers we know we can trust in iozone3 results with small test sizes and this SSD known to exceed 500 MB/s on a SATA 3.0 port is good for 360 MB/s with RK3328. Now with a VIA812 hub in between testing the EVO 840 with 100 MB again as above: Samsung EVO 840 (slowest 120 GB model, small TurboWrite buffer) with UAS behind VIA 812: random random kB reclen write rewrite read reread read write 102400 4 17623 22594 22798 21271 17063 19918 102400 16 59893 65823 77422 77771 60776 72342 102400 512 298044 309659 295337 304488 294191 315187 102400 1024 326897 337167 316500 324801 323386 344312 102400 16384 357958 363964 340186 360812 360139 363830 1
tkaiser Posted July 6, 2017 Posted July 6, 2017 Now a second SSD (very slow Intel 540) in a second JMS567 connected to the VIA 812: root@rock64:/home/rock64# lsusb Bus 005 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. Bus 005 Device 004: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 005 Device 003: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 005 Device 002: ID 2109:0813 Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 002: ID 2109:2813 Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@rock64:/home/rock64# lsusb -t /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 4: Dev 5, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M I created a btrfs raid-0 (mkfs.btrfs -f -m raid0 -d raid0 /dev/sda1 /dev/sdb2) and tried it again: Samsung EVO 840 and Intel 540 as RAID-0 with UAS behind VIA 812: random random kB reclen write rewrite read reread read write 102400 4 7760 6563 15659 15284 11590 4870 102400 16 21240 16059 49077 39481 39938 11588 102400 512 158914 128861 126339 127106 122961 134573 102400 1024 169372 173392 152526 128089 128313 167697 102400 16384 257307 1592 287695 284334 288541 241423 Shitty performance as expected and especially the 16M rewrite horribly low due to the yet missing fix for an USB3 PHY issue currently present on RK3328: https://pastebin.com/wkkdgV4J RAID at home is stupid anyway but once the USB3 issues are fixed upstream I would believe adding more than one disk to a ROCK64 and accessing them even at the same time won't be an issue since performance will still be way faster than the Gigabit Ethernet bottleneck here (if you look closely my USB hub also contains an RTL8153 Gigabit Ethernet USB chip -- the same that is used on ODROID-XU4 BTW -- so most probably later we see crazy folks doing crazy stuff like using a ROCK64 as iSCSI server utilizing Multipathing to serve clients with up to 220MB/s) 1
infinity Posted July 6, 2017 Posted July 6, 2017 @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.
tkaiser Posted July 6, 2017 Posted July 6, 2017 21 minutes ago, infinity said: Damn, thats really impressive! This thingy looks like it is going to bring load of fun for littel NAS and server applications. Obviosly not comparable to Synlogoy or similar, but it is also not meant to compete with such devices. Well, we have to keep in mind that this is just a TV box SoC and not designed for serious storage tasks. Especially the choice of protocols/connectors is not comparable. Please look at the dmesg output starting from 15.730777. That was me testing with a JMS567 enclosure and running in all sorts of errors. I shut the board down, reinserted the cable --> problem gone. When testing with the cable not properly inserted it looked like this (please notice the orange triangles which show minimum and maximum values since bus resets happened and other stuff -- surprisingly no filesystem corruption): In other words: Cabling/connector issues are quite common with USB3. USB3 cables/receptacles have 5 more contacts than USB2 gear and those are f*cking small compared to the 2 contacts used for Hi-Speed/USB2 data lines. Only if cables really fit exactly and are inserted fully you won't run in troubles: USB3 is cheap consumer electronics crap and you need to pay a lot of attention to such stuff! For the USB2 data lines it doesn't matter much whether the cable is completely inserted or not but those small USB3 contacts need 'full contact' and since the SuperSpeed data lines are on the outer contacts small movements of the cable can negatively impact connectivity (you touch the cable, it's now inserted with 3° instead of 0° and problems start). In case I'll ever build a small NAS with a ROCK64 there are 3D printed parts needed to properly fix the cable since everything else is just plain stupid. Even HDD vibrations can lead to contact problems over time if the cable is not properly fixated! And now have a look how 'Mini SAS' or SATA look like. The contact surface is much MUCH larger, some cable bending is exactly no problem and there are metal latches by design to fixate cable/connector: And then all serious storage protocols know mechanisms to deal with cable/connector problems. With SATA for example we have SMART attribute 199. If this value increases this indicates a cable/connector problem since SATA uses some checksumming to ensure data integrity. SMART counter 199 should increase if this happens so you know exactly where to look at. With USB3/UAS the error messages read like 'uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT' and people get crazy yelling 'UAS is evil!' while they would run in exactly the same problems without UAS but then the error messages read differently. 1
Xalius Posted July 6, 2017 Author Posted July 6, 2017 Yeah the connectors for USB3-A are tricky. On my old Thinkpad the lower USB3 port which I used a lot more than the upper port enumerates half the time only as high speed instead of super speed because it seems to be worn out, I also noticed some USB3 connectors fit a lot tighter than others... I wonder if there is some low level stats we can pull out of Linux to see USB transmissions errors as an indicator for bad cable connections? Edit: apparently there is this https://wiki.wireshark.org/CaptureSetup/USB 2
tkaiser Posted July 6, 2017 Posted July 6, 2017 32 minutes ago, Xalius said: Yeah the connectors for USB3-A are tricky. There's a reason Apple sent truckloads of engineers to USB Implementers forum technical commitees for 'next generation connector' and power delivery specs to avoid such BS (or that Micro USB crap). But it will take some time until we see USB-C everywhere -- especially implemented correctly 2
TonyMac32 Posted July 14, 2017 Posted July 14, 2017 *chirp chirp chirp* I'm still waiting on mine to make the slow boat ride from China, anything new come up? *edit* looks like schematic 2.0 is available. @Xalius , what tool did you use to copy the first 16 MB over to the SPI-NOR?
Xalius Posted July 14, 2017 Author Posted July 14, 2017 10 hours ago, TonyMac32 said: *chirp chirp chirp* I'm still waiting on mine to make the slow boat ride from China, anything new come up? *edit* looks like schematic 2.0 is available. @Xalius , what tool did you use to copy the first 16 MB over to the SPI-NOR? I use either flashcp or nandwrite from the mtd-tools, those can work directly on /dev/mtd0 or partitions.. 1
Da Alchemist Posted July 14, 2017 Posted July 14, 2017 Just for the Record, i have Ayufan´s Xenial-Mate-Rock64-Armhf Image running on a Z28 TVBox 1GbRam/8Gb Emmc....
r1kaomsk Posted July 15, 2017 Posted July 15, 2017 9 hours ago, Da Alchemist said: Just for the Record, i have Ayufan´s Xenial-Mate-Rock64-Armhf Image running on a Z28 TVBox 1GbRam/8Gb Emmc.... What kind of tools you used for flashing?
Xalius Posted July 20, 2017 Author Posted July 20, 2017 I added some experimental tweaks to my development image to enable HS-200 mode for the eMMC ( was SDR50 before just like the SD card). I will submit a proper patch for ayufan's BSP linux branch during this week. To get HS-200 mode working, there were some clock definitions (looking at you, ciu-sample and drive clocks...) missing and some properties (maximum bus frequency) I had to add to the rk3328.dtsi... but it seems to run stable now... Some iozone results before and after switching SDR50 to HS-200: ---------------- SDR50 --------------------------------------------- random random kB reclen write rewrite read reread read write 512000 4 3430 3554 10964 10472 8152 1614 512000 16 7064 7647 25009 25242 2069 6249 512000 512 10800 11494 41555 43169 42551 10620 512000 1024 11228 11736 42159 43690 43338 10890 512000 16384 11258 11733 44909 44825 44875 11165 ----------------- HS-200 ------------------------------------------- 512000 4 3414 3399 17914 8218 11523 1752 512000 16 9078 9804 56272 56583 39466 7190 512000 512 13173 14054 119128 118530 116335 13008 512000 1024 13816 14607 117665 121782 120387 13429 512000 16384 13814 14662 122756 124242 123471 14007 It seems we are getting close to the 140MB/s read performance the datasheet promises, but 15MB/s is still short of the 35MB/s write performance according to the datasheet, so any hints are welcome here... I would also like some advice on the phase correction loop sublayer in the generic mmc driver, how does one pre calculate the default phase shift? 1
hojnikb Posted July 21, 2017 Posted July 21, 2017 Maybe 35MB/s write is just burst for the first few 100MBs (with simulated SLC cache) and when it runs out it drops back to "normal".
TonyMac32 Posted July 21, 2017 Posted July 21, 2017 My board finally escaped customs, I should have it late next week.
infinity Posted July 22, 2017 Posted July 22, 2017 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)?
Xalius Posted July 22, 2017 Author Posted July 22, 2017 I either use the eMMC adapter that came with one of my ODROIDs or write to the eMMC from a sdcard image. There is also a flash tool from RK that uses USB-OTG via USB A-to-A cable... As for heatsinks, I mounted a small 14x14x14mm sink since I build a lot on my Rock64 and that keeps it from throttling with all four cores running at 1.3Ghz. The RK3328 is implemented with 28nm node, not sure what S905 uses? http://www.fischerelektronik.de/web_fischer/en_GB/heatsinks/B01/Heatsinks for PGA/PR/ICKPGA14x14x14_/index.xhtml 1
TonyMac32 Posted July 22, 2017 Posted July 22, 2017 For Pi form factor boards I've been using a 25 x 50 mm aluminum heatsink available on Amazon, top left in image. 1
infinity Posted July 23, 2017 Posted July 23, 2017 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?
tkaiser Posted July 23, 2017 Posted July 23, 2017 16 hours ago, infinity said: I wonder how you guys write to eMMC. Since I would believe this eMMC connector isn't made for much matings I prefer to leave the eMMC where it is. Then there are three opportunities: Use a male-to-male USB cable, get the device into MaskRom mode (google --> 'maskrom site:armbian.com') and flash the eMMC directly from a host device Burn an image to SD card, boot ROCK64 from SD card and then use whatever mechanism to either overwrite the eMMC with a complete OS image or use later Armbian's nand-sata-install to transfer the installation from SD card to eMMC When community+RK got an universal bootloader working and Pine Inc starts to flash this to the SPI NOR flash on the board a guided installation routine will eventually be possible that fetches an OS of choice from the Internet or locally and then overwrites the eMMC with this (device specific bootloader remaining on the SPI NOR flash, OS image being device agnostic). Not yet ready and I doubt we're talking here about 2017 too With my testings so far I had a hard time getting ROCK64 to throttle with normal workloads and the currently implemented DVFS OPP table (maxing out at 1296 MHz). This might look differently when we add more DVFS OPP to reach the advertised 1.5GHz (since then Vcore voltage has also to be increased and then throttling is more likely to occur). You should also keep in mind that ODROID-C2 has a better GPU than ROCK64 and Hardkernel folks in the beginning thought they would deal with a 2.0GHz SoC here (just to discover later that Amlogic's blobs simply reported wrong cpufreq and limited max cpufreq to 1.5GHz anyway). So the heatsink on C2 is both slight overkill but also sufficient to not run into throttling situations there unless you use really stupid small enclosures. On ROCK64 I tested with my usual el cheapo $0.5 heatsink and this was responsible for maybe ~5°C less and throttling jumping in later (I used cpuburn-a53 which is the most heavy CPU load I currently know of for A53 cores). Putting ROCK64 in an upright position allowing the PCB bottom to receive some airflow instead of placing it on a pillow had a similar effect. I would believe most of the heat gets dissipated into the PCB below the SoC already. 1
Xalius Posted July 30, 2017 Author Posted July 30, 2017 I just booted a mainline kernel on my Rock64 (4.12-rc7 with defconfig, rest was from ayufan's minimal xenial image) and that seems to work ok. Currently investigating a problem with the GMAC0 not finding the PHY, so no network at the moment, but USB2 seems to work, USB3, video and audio drivers are not there yet... Boot log: http://pastebin.ubuntu.com/25206030/ I guess I will try 4.12.4, 4.13-rc2 and rockchip-next as well... 3
mdel Posted August 7, 2017 Posted August 7, 2017 hello could someone post some figures for ssl performance on that rk3328 cortex A53 soc : openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc please specify your board ram configuration (1/2/4GB), it seems ram (larger/faster bus) has quite an impact on those performances. thx
tkaiser Posted August 7, 2017 Posted August 7, 2017 (edited) On 07/08/2017 at 5:33 PM, mdel said: could someone post some figures for ssl performance on that rk3328 cortex A53 soc Benchmarks test software not hardware Here you go: Debian Jessie armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 44271.21k 52204.07k 55156.22k 56023.72k 56142.51k aes-256 cbc 34693.89k 39353.94k 41079.04k 41499.31k 41645.40k bf-cbc 29864.52k 37308.12k 39764.57k 40467.80k 40667.82k Debian Stretch armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 42906.97k 51552.64k 54543.45k 55381.67k 55536.30k 55437.99k aes-256 cbc 29686.84k 37227.41k 39764.91k 40532.99k 40719.70k 40654.17k bf-cbc 28744.72k 39247.51k 43142.74k 44282.20k 44583.59k 44569.94k Debian Stretch arm64: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 41623.29k 44895.06k 46213.89k 46552.41k 46620.67k 46574.25k aes-256 cbc 33123.65k 35228.65k 36029.53k 36235.26k 36268.71k 36235.95k bf-cbc 29389.00k 39838.93k 43663.10k 44790.10k 45118.81k 45105.15k Ubuntu Xenial armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 44997.09k 51821.85k 54241.71k 54892.20k 55025.66k aes-256 cbc 34964.21k 38755.18k 40066.39k 40408.06k 40501.25k bf-cbc 32691.63k 38896.87k 40785.58k 41335.13k 41487.02k Ubuntu Xenial arm64: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 40718.71k 44137.43k 45305.69k 45607.59k 45662.21k aes-256 cbc 32820.84k 34230.12k 34952.36k 35160.41k 35687.08k bf-cbc 33233.00k 39495.68k 41386.75k 41935.19k 42087.77k In case any moderator cares about readability please add spoiler tags for the following (I will never use this functionality again with this interactive forum mess here): RK3328 allowed to clock at 1296 MHz max. Numbers below for Debian Jessie armhf userland running on 2GB and 4GB ROCK64 (same single bank DRAM config using same slower 1600 MHz DRAM settings on all boards BTW): Spoiler 4GB/armhf: root@rock64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 8230706 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2455789 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 647968 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 164304 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 20517 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6497443 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1846899 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 480433 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 121630 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 15222 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 5611448 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1752438 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 465283 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 118437 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 14864 bf-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Jan 27 00:26:25 2017 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 43897.10k 52390.17k 55293.27k 56082.43k 56025.09k aes-256 cbc 34653.03k 39400.51k 40996.95k 41516.37k 41566.21k bf-cbc 29927.72k 37385.34k 39704.15k 40426.50k 40588.63k root@rock64:~# free total used free shared buffers cached Mem: 4020056 451412 3568644 27896 14464 328152 -/+ buffers/cache: 108796 3911260 Swap: 0 0 0 root@rock64:~# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/cMOL Please post the above URL on the forum where you've been asked for it. 2GB/armhf: root@rock64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 8300852 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2447066 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 646362 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 164132 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 20560 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6505104 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1844716 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 481395 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 121580 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 15251 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 5599597 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1748818 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 465991 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 118558 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 14893 bf-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Jan 27 00:26:25 2017 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 44271.21k 52204.07k 55156.22k 56023.72k 56142.51k aes-256 cbc 34693.89k 39353.94k 41079.04k 41499.31k 41645.40k bf-cbc 29864.52k 37308.12k 39764.57k 40467.80k 40667.82k root@rock64:~# free total used free shared buffers cached Mem: 1975212 217108 1758104 25464 12120 112972 -/+ buffers/cache: 92016 1883196 Swap: 0 0 0 root@rock64:~# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/ZSRW Please post the above URL on the forum where you've been asked for it. No differences wrt DRAM size (as expected). Now using a Debian Stretch arm64 userland on 4GB board: root@rock64:/home/rock64# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 7804367 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2104456 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 541569 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 136384 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 17073 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 16384 size blocks: 8528 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6210685 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1651343 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 422221 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 106158 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 13282 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 16384 size blocks: 6635 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 5510437 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1867450 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 511677 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 131221 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 16523 bf-cbc's in 3.00s Doing bf-cbc for 3s on 16384 size blocks: 8259 bf-cbc's in 3.00s OpenSSL 1.1.0f 25 May 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 41623.29k 44895.06k 46213.89k 46552.41k 46620.67k 46574.25k aes-256 cbc 33123.65k 35228.65k 36029.53k 36235.26k 36268.71k 36235.95k bf-cbc 29389.00k 39838.93k 43663.10k 44790.10k 45118.81k 45105.15k root@rock64:/home/rock64# free total used free shared buff/cache available Mem: 4020056 44540 3849972 8448 125544 3936988 Swap: 0 0 0 root@rock64:/home/rock64# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/hCeH Please post the above URL on the forum where you've been asked for it. Now Ubuntu Xenial arm64 on the 4 GB board: root@rock64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 7634759 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2068942 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 530926 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 133616 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 16722 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6153907 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1604537 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 409598 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 103009 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 13069 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 6231187 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1851360 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 485001 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 122857 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 15413 bf-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 40718.71k 44137.43k 45305.69k 45607.59k 45662.21k aes-256 cbc 32820.84k 34230.12k 34952.36k 35160.41k 35687.08k bf-cbc 33233.00k 39495.68k 41386.75k 41935.19k 42087.77k root@rock64:~# free total used free shared buff/cache available Mem: 4020056 28684 3847976 8448 143396 3939604 Swap: 0 0 0 root@rock64:~# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/eCcI Please post the above URL on the forum where you've been asked for it. And now finally Ubuntu Xenial armhf on the 4 GB board: root@rock64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 8436954 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2429149 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 635645 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 160817 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 20151 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6555789 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1816649 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 469528 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 118383 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 14832 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 6129681 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1823291 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 477956 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 121099 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 15193 bf-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 44997.09k 51821.85k 54241.71k 54892.20k 55025.66k aes-256 cbc 34964.21k 38755.18k 40066.39k 40408.06k 40501.25k bf-cbc 32691.63k 38896.87k 40785.58k 41335.13k 41487.02k root@rock64:~# free total used free shared buff/cache available Mem: 4020056 26360 3859864 8448 133832 3942152 Swap: 0 0 0 root@rock64:~# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/EWRI Please post the above URL on the forum where you've been asked for it. And finally 'stock' Debian Stretch image from here: http://wiki.pine64.org/index.php/ROCK64_Main_Page#Stock_Build_Debian_Jessie_LXDE_Linux_Kernel_ver_4.4_.5BmicroSD_Boot.5D_.5B20170705.5D_Pre-Release_version root@linaro-alip:/home/linaro# lsb_release -c Codename: stretch root@linaro-alip:/home/linaro# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 8045057 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2416530 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 639181 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 162251 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 20338 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 16384 size blocks: 10151 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 5566282 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1745035 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 465995 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 118749 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 14912 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 16384 size blocks: 7444 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 5389635 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1839727 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 505579 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 129733 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 16327 bf-cbc's in 3.00s Doing bf-cbc for 3s on 16384 size blocks: 8161 bf-cbc's in 3.00s OpenSSL 1.1.0e 16 Feb 2017 built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/arm-linux-gnueabihf/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 42906.97k 51552.64k 54543.45k 55381.67k 55536.30k 55437.99k aes-256 cbc 29686.84k 37227.41k 39764.91k 40532.99k 40719.70k 40654.17k bf-cbc 28744.72k 39247.51k 43142.74k 44282.20k 44583.59k 44569.94k root@linaro-alip:/home/linaro# file $(which openssl) /usr/bin/openssl: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=c14ec07b1c33d019cab7024195ccefb454bc0c37, stripped root@linaro-alip:/home/linaro# free total used free shared buff/cache available Mem: 4019968 119588 3710644 26580 189736 3843704 Swap: 0 0 0 root@linaro-alip:/home/linaro# dmesg | curl -F 'sprunge=<-' http://sprunge.us http://sprunge.us/IhXf Edited August 8, 2017 by pfeerick spoiler as hinted for
mdel Posted August 7, 2017 Posted August 7, 2017 @tkaiser thx for the very thorough test, and 2/4GB comparison, at least that is clear. i'm a bit surprised by the lower performances of arm64 builds, do you have any idea what's going on there ? armhf figures are almost identical to my Amlogic s905 devices (around 56k for aes-128 which is always the fastest for some reason). It's interesting to see that it has about the same performance at 1296MHz as the s905 at 1.75GHz (?, well the fake 2GHz..) I was looking at the recently published rockchip documentations (3288 and 3328), and i'm quite surprise to find almost nothing concerning the HW Crypto block, something like only one register address.. I'm assuming those "amrv8 cryptography extensions" are the same on all a53 socs but was never included in a linux kernel which sounds odd to me, but i don't know anything about it so.. I'm still not sure if it has to be declared in the Device Tree to be accessible by the kernel, if that's the case then i believe i've never seen it in those cheap socs DTs and is totally ignored by everyone. I vaguely recall seeing it mentioned on a timeline from a baylibre presentation about amlogic mainlining. So far the only soc i saw that had crypto hw support (displayed on cpuinfo "Features") is the Marvell 3700 from Espressobin board, not sure it can be used though. The driver apparently also exist but not for that family, so i guess it's a matter of time until it's ported to that Marvell soc, i doubt adding compatibility flags would suffice. thx again for the benchmarks. -- off topic -- if anyone's interested with a 56k value you should be able to achieved an absolute max of 80-90Mbps with openvpn (single thread). so in that context it would be definitely a bottleneck bandwidth wise, usb3 (well even usb2) and Gbe would be only useful in a unencrypted/lan context.
tkaiser Posted August 8, 2017 Posted August 8, 2017 15 hours ago, mdel said: It's interesting to see that it has about the same performance at 1296MHz as the s905 at 1.75GHz (?, well the fake 2GHz..) Amlogic's S9xx SoCs are limited to 1.5GHz by default without overclocking. And no, not the slightest idea about the differences in numbers between armhf/arm64 but in 'active benchmarking' mode this would be the begin of the journey trying to figure out why that happens to improve numbers.
Stuart Naylor Posted August 8, 2017 Posted August 8, 2017 I am not much of a developer as my skills are more rust. As an end user the two products that are of most interest to me are the Rock64 & Helios4. Rock64 with the 4GB is sort of an allrounder with the Mali & USB 3.0 with the possibility of just hooking it up to OEM 4bay USB Jbod/Raid box, NAS with maybe KODI on top. Helios4 really interested in that NAS specific design, but got a feeling the Rock64 will garner more interest as a building block rather than a specific solution. I just purchased a Rock64 and hopefully can glean some wisdom from you guys. [Edit]http://espressobin.net/ looks pretty interesting and again opens up router / nas solutions. Still think the Rock64 offers a bit less but may be more general purpose that sort of fits its budget.
Shimon Posted August 8, 2017 Posted August 8, 2017 16 hours ago, mdel said: i'm a bit surprised by the lower performances of arm64 builds, do you have any idea what's going on there ? I noticed the issue a few months ago, and, as the ARMv7 binaries produced the expected results in AARCH32 mode, I looked at the source and IIRC it was all about optimized assembly routines not present in the AARCH64 version. edit: In case I'm misremembering, it could have been about cpuminer results.
TonyMac32 Posted August 10, 2017 Posted August 10, 2017 A 4.13 DTS patch just popped up on patchwork for Rock64, in case anyone is interested. https://patchwork.kernel.org/patch/9892325/ There was a small mountain of patches stuffed in there yesterday, should go through them
TonyMac32 Posted August 17, 2017 Posted August 17, 2017 Armbianmonitor may need tweaked for Aarch64, I got the same result on Le Potato Selecting previously unselected package libcurl4-gnutls-dev:arm64. (Reading database ... 123334 files and directories currently installed.) Preparing to unpack .../libcurl4-gnutls-dev_7.47.0-1ubuntu2.2_arm64.deb ... Unpacking libcurl4-gnutls-dev:arm64 (7.47.0-1ubuntu2.2) ... Processing triggers for man-db (2.7.5-1) ... Setting up libcurl4-gnutls-dev:arm64 (7.47.0-1ubuntu2.2) ... checking build system type... aarch64-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking target system type... aarch64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/usr/local/src/cpuminer-2.4.5': configure: error: C compiler cannot create executables See `config.log' for more details make: *** No targets specified and no makefile found. Stop. section of config.log: Spoiler COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ub$ Thread model: posix gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) configure:3436: $? = 0 configure:3425: gcc -V >&5 gcc: error: unrecognized command line option '-V' gcc: fatal error: no input files compilation terminated. configure:3436: $? = 1 configure:3425: gcc -qversion >&5 gcc: error: unrecognized command line option '-qversion' gcc: fatal error: no input files compilation terminated. configure:3436: $? = 1 configure:3456: checking whether the C compiler works configure:3478: gcc -O3 -mfpu=neon conftest.c >&5 gcc: error: unrecognized command line option '-mfpu=neon'
willmore Posted August 17, 2017 Posted August 17, 2017 FWIW, here are results from an Odroid-C2 (s905 at 1.752 GHz) root@odroid64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 10626464 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2854954 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 732698 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 184400 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 23091 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 8492125 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 2213547 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 564986 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 141955 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 17779 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 8588780 bf-cbc's in 2.99s Doing bf-cbc for 3s on 64 size blocks: 2551326 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 668702 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 169460 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 21263 bf-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 56674.47k 60905.69k 62523.56k 62941.87k 63053.82k aes-256 cbc 45291.33k 47222.34k 48212.14k 48453.97k 48548.52k bf-cbc 45960.03k 54428.29k 57062.57k 57842.35k 58062.17k I'm new to reporting this, so if there was more info you need, let me know and I'll do my best to get it to you.
Stuart Naylor Posted August 18, 2017 Posted August 18, 2017 I only have a 100Mb USB ethernet but just wondered has anyone tried port trunking a USB3.0 1Gb with the on-board just to have a glance at the workload & throughput? Aint got the board yet, but apols interested. Also wondered what your thoughts on the Jmicron JMS561 2 port USB RAID controller? Not much more than a normal usb to sata adaptor https://www.alibaba.com/product-detail/Dual-SATA-USB3-0-hdd-Adapter_60670388309.html?spm=a2700.7724838.2017115.9.3c93b095xybUP4 Funny though to put the connectors like that rather than oppisite ends on top and bottom of the case so it goes between 2 drives or sits on a single... 8gb mirror 16gb stripe and I am guessing its a JMS561 but prob is and not as jbod so it just looks like a single drive? PS a tv box has turned up with gig ethernet like the Rock http://www.cnx-software.com/2017/07/14/bqeel-mvr9-tv-box-review-part-1-specifications-unboxing-and-teardown/ DDR4 as well but only 2Gb
Recommended Posts