ROCK64

[Xalius]

Moderator edit (pfeerick): I have modified this post to contextualise this split thread. It was initially intended to be a discussion of a board bring up procedure / proposal format, and has since evolved into discussion of the rock64 generally. 

 

Xalius originally said in this post: 

TODO-List sounds good to me, I will run some tests as soon as China Post/DHL actually deliver my package. I get a 4GB version with the suppressor diodes for USB3 already replaced...

 

This is what tkasier originally wrote in his first post, minus the disclaimer as was only relevant to that thread:

 

Quote

 

Let me introduce ROCK64:

 

• RK3328 SoC: feature list
• ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks)
• Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit)
• 1GB, 2GB or 4GB PC-18666 LPDDR3
• eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper)
• socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter)
• 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever)
• RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth)
• Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked)
• I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this)
• Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)

 

Pros:

• board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor)
• board vendor provides dev samples and documents problems devs might run into (see below)
• chip vendor actively supports mainline Linux and u-boot
• chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC)
• SDK/BSP not horribly outdated (RK relies currently on 4.4)
• almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces)
• No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook
• Icenowy already received a dev sample 

 

Cons:

 

• new platform (Rockchip 64-bit) needing more initial work

 

Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all)

 

My next steps planned:

 

• Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks)
• Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution)
• ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering)
• Present results to continue discussion

 

 

[tkaiser]

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)

 

[infinity]

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

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.

[Xalius]

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

[tkaiser]

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  

[TonyMac32]

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

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

[Da Alchemist]

Just for the Record, i have Ayufan´s Xenial-Mate-Rock64-Armhf Image running on a Z28 TVBox  1GbRam/8Gb Emmc....

[r1kaomsk]

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?

[Da Alchemist]

The TV Box Topic is here.

.

[Xalius]

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? 

[hojnikb]

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]

My board finally escaped customs, I should have it late next week.

[infinity]

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]

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

[TonyMac32]

For Pi form factor boards I've been using a 25 x 50 mm aluminum heatsink available on Amazon, top left in image. 

[infinity]

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]

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.

 

[Xalius]

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

[mdel]

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]

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]

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

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]

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]

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]

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]

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]

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]

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 
 

[tkaiser]

On 18.8.2017 at 8:26 AM, Stuart Naylor said:

has anyone tried port trunking a USB3.0 1Gb with the on-board just to have a glance at the workload & throughput?

 

RK3328 can saturate the internal GbE MAC in combination with the external RTL8211 PHY (please note: On pre-production samples we had 8211E while production boards feature 8211F, no idea yet what this means wrt performance/consumption) as well as an RTL8153 USB GbE dongle. With appropriate IRQ affinity also at the same time. With synthetical benchmarks you get then ~1700 Mbits/sec combined.

 

Now let's talk about use cases:

• When we're talking about 'trunks' then this is usually called link aggregation (IEEE 802.1AX-2008 formerly known as IEEE 802.3ad). This mode does NOT increase bandwidth for networking connections but only provides a mechanism to put individual node connections on either link. So you will NOT end up with 2 Gbits/sec but with 2 x 1 Gbits/sec instead. The algorithm used to determine which link to put which connection on has to be chosen carefully since it's pretty easy to configure everything in a way that all traffic remains on one link while the other is unused. In n-to-1 topologies n should be at least 10 for trunking/bonding/LACP to become useful
• What to do with 2 x 1 Gbits/sec? Which data to transmit? If the USB3 port is occupied by a RTL8153 the remaining interfaces are 2 x USB2 (each ~40 MB/s when 'USB Attached SCSI' (UAS) can be used, otherwise it's save to assume 35MB/s max) or eMMC and SD card. Even with implementing RAID-0 on the 2 USB2 ports we're not close to getting an IO bandwidth satisfying a 2nd GbE NIC. So we would need USB3 storage too and then there's the need to add an USB3 hub.
• There exist different kinds of USB3 hubs and especially older ones are error prone. Based on some research a year ago I believe(d) choosing an USB3 hub based on VIA812 is a good idea. There exist also some VIA812/RTL8153 combinations (like the one you can see on this picture I bought for ~20 bucks few months ago -- in the same thread at the top you see also some performance numbers and should also keep in mind that ODROID XU4/HC1 use this very same chip for their onboard GbE).
• To make use of an additional RTL8153 with storage use cases we would need to put an USB3 hub in between and then I'm already somewhat concerned with regard to reliability (the more complexity the less reliability).
• Next problem: sequential transfer speed limits of HDDs: even with the fastest 3.5" HDDs currently available due to ZBR (zone bit recording) sequential transfer speeds drop below 100 MB/s if the disk gets filled (top sequential speeds are only possible with empty disks when you benchmark on the outer disk tracks). To make use of 2 GbE links we would need to combine also at least two disks in a RAID-0 fashion. This is dangerous since a single disk fail will render all your data unusable.
• So what about redundant RAID modes? If we use such a VIA812/RTL8153 combination we could at least connect 3 disks and play RAID-5. Then we're switching from dangerous to insanely dangerous since from the on the USB hub acts as a single point of failure. Let there some USB resets happen for whatever reasons: all 3 disks behind the hub are not accessible so mdraid code will trash the whole array (please believe me: I deal now with failing RAIDs for exactly 2 decades and can tell you that RAID is only great until you would need it)
• Then you need a bunch of external PSUs and a whole mess of cables to setup such a multi disk environment and if you add all the costs you might realize that ROCK64 is a great single disk NAS but if you have to add more than one disk other solutions like Helios4 or a x64 based HP Microserver look more sufficient (or Marvell based solutions like Clearfog or Espressobin where you get between 1 and 5 or even 9 real SATA ports without any USB3 crappiness in between)

TL;DR: It's possible to implement trunking, performance with synthetical benchmarks will look nice if you benchmark with 2 clients and add bandwidth (quite unrealistic of course) but I fail to identify a single use case that would justify trunking with a RK3328 device like ROCK64. Most probably the idea is not trunking but aggregated bandwidth like it's possible with some LAN protocols (for example 'SMB Multichannel' available since Windows 2012 server -- really impressive stuff) or SAN topologies (iSCSI multipathing for example). But then still due to the single USB3 port on RK3328 it's a really bad idea since added storage means more complexity (USB hub in between) and this negatively affects reliability.

 

Wrt JMS561 (USB-to-SATA bridge combined with SATA port multiplier and primitive RAID engine) please check @Kosmatik's experiences (ODROID-XU4 user running in a lot of problems with Hardkernel's Cloudshell 2 device that relies on this chip). Due to the issues reported here and there I would not use any device based on JMS561 (or older such chips like JMS539). But based on my experiences with failed RAID and my tries to avoid single points of failure I would never use any of these proprietary chips anyway.