Jump to content

ROCK64


Xalius

Recommended Posts

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

 

Link to comment
Share on other sites

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)

 

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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):

Bildschirmfoto%202017-07-06%20um%2010.39

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:

usb_3_4.jpg

 

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:

SATA_Cables_metal_latch.jpg

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 :( 

Link to comment
Share on other sites

*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?

Link to comment
Share on other sites

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..

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

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)?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by pfeerick
spoiler as hinted for
Link to comment
Share on other sites

@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.

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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'

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 
 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines