What are your cryptsetup benchmark results on your ODROID?

Post Reply
sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

What are your cryptsetup benchmark results on your ODROID?

Unread post by sha256 » Sat Dec 12, 2015 8:07 am

Hey,

I'm going to buy a new ODROID soon. I'm curious what the encryption speeds are up to on new models especially (XU4), but any other fine for comparison.

Could some people with a XU4 or other run cryptsetup benchmark and post results here?

On Debian/Ubuntu you just have to have cryptsetup installed:

Code: Select all

sudo apt-get install cryptsetup
and then run the command:

Code: Select all

sudo cryptsetup benchmark
Would be great to see the difference. For reference, the low-end computer I'm typing from gets (Intel Atom N450):

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       187245 iterations per second
PBKDF2-sha256      92827 iterations per second
PBKDF2-sha512      73142 iterations per second
PBKDF2-ripemd160  104690 iterations per second
PBKDF2-whirlpool   27489 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    31.8 MiB/s    27.4 MiB/s
 serpent-cbc   128b    29.4 MiB/s    58.3 MiB/s
 twofish-cbc   128b    26.3 MiB/s    30.9 MiB/s
     aes-cbc   256b    23.4 MiB/s    22.3 MiB/s
 serpent-cbc   256b    29.4 MiB/s    50.7 MiB/s
 twofish-cbc   256b    27.2 MiB/s    30.9 MiB/s
     aes-xts   256b    30.9 MiB/s    30.6 MiB/s
 serpent-xts   256b    59.4 MiB/s    41.7 MiB/s
 twofish-xts   256b    29.0 MiB/s    31.7 MiB/s
     aes-xts   512b    22.8 MiB/s    24.0 MiB/s
 serpent-xts   512b    59.0 MiB/s    38.1 MiB/s
 twofish-xts   512b    29.4 MiB/s    31.7 MiB/s
Thanks for reading

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Sat Dec 12, 2015 8:12 am

Crap, I"m sorry, I didn't see the other thread in search engine.
http://forum.odroid.com/viewtopic.php?f ... up#p101808

Nevermind!

elatllat
Posts: 1136
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by elatllat » Sat Dec 12, 2015 2:24 pm

Yes the XU4 is nice, I wonder how much faster up-board will be.

stmicro
Posts: 236
Joined: Tue Apr 28, 2015 4:23 pm
languages_spoken: english, chinese
ODROIDs: Many Odroids and Rpis.
Location: shenzhen china
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by stmicro » Sat Dec 12, 2015 4:52 pm

I've run the bench on my XU4.

Code: Select all

odroid@odroid:~$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       310229 iterations per second
PBKDF2-sha256     197100 iterations per second
PBKDF2-sha512     126030 iterations per second
PBKDF2-ripemd160  242725 iterations per second
PBKDF2-whirlpool   31207 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   449.5 MiB/s   453.0 MiB/s
 serpent-cbc   128b    38.8 MiB/s    39.2 MiB/s
 twofish-cbc   128b    53.5 MiB/s    56.7 MiB/s
     aes-cbc   256b   460.7 MiB/s   479.0 MiB/s
 serpent-cbc   256b    38.6 MiB/s    39.4 MiB/s
 twofish-cbc   256b    52.7 MiB/s    55.7 MiB/s
     aes-xts   256b    51.0 MiB/s    52.0 MiB/s
 serpent-xts   256b    39.2 MiB/s    38.8 MiB/s
 twofish-xts   256b    54.7 MiB/s    55.7 MiB/s
     aes-xts   512b    41.6 MiB/s    41.6 MiB/s
 serpent-xts   512b    38.8 MiB/s    38.4 MiB/s
 twofish-xts   512b    54.5 MiB/s    56.2 MiB/s
odroid@odroid:~$ 
It looks like that XU4 is 2~5 times faster than your old Atom. :D

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Sun Dec 13, 2015 12:30 am

Yep that was part of why I was asking :). Thanks. This atom is old, but it still beat out Pis.

However the ODRIOD doesn't seem to be 5 times faster across the board. Serpent is still faster on this old Atom and most of the ciphers are comparable. It only seems to be extremely faster for AES-CBC. So I'm assuming AES-CBC is hardware-accelerated on the XU4. I find it unusual. On every intel I've used with AES hardware acceleration it's been for AES on any mode (CBC, XTS, etc.).

This leads me to londer which applications will be accelerated in practice. OpenSSL? SSH? Maybe OpenSSL/TLS, but SSH has different modes so I have my doubts it will be generally covered.

I suppose you'd have to benchmark the SSH ciphers to find out. SSH does support AES-CBC specifically, but it's not the most recommended mode. I don't even have it enabled (Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr).

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Tue Dec 22, 2015 10:33 am

I was finally able to test this on my own, and this XU4 gets the same numbers on Ubuntu 15.04, consistent:

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       310229 iterations per second
PBKDF2-sha256     195629 iterations per second
PBKDF2-sha512     127254 iterations per second
PBKDF2-ripemd160  238312 iterations per second
PBKDF2-whirlpool   31356 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   443.8 MiB/s   455.0 MiB/s
 serpent-cbc   128b    36.5 MiB/s    37.9 MiB/s
 twofish-cbc   128b    50.0 MiB/s    55.3 MiB/s
     aes-cbc   256b   443.8 MiB/s   438.1 MiB/s
 serpent-cbc   256b    38.2 MiB/s    38.6 MiB/s
 twofish-cbc   256b    50.7 MiB/s    56.3 MiB/s
     aes-xts   256b    50.9 MiB/s    51.6 MiB/s
 serpent-xts   256b    39.3 MiB/s    38.2 MiB/s
 twofish-xts   256b    54.0 MiB/s    55.7 MiB/s
     aes-xts   512b    41.4 MiB/s    41.7 MiB/s
 serpent-xts   512b    39.1 MiB/s    38.4 MiB/s
 twofish-xts   512b    53.5 MiB/s    55.7 MiB/s
However I tried the minimal Debian Jessie image afterward, and there even with performance governor, it doesn't exploit full acceleration on aes-cbc:

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       301314 iterations per second
PBKDF2-sha256     189959 iterations per second
PBKDF2-sha512     124830 iterations per second
PBKDF2-ripemd160  231985 iterations per second
PBKDF2-whirlpool   31356 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   141.6 MiB/s   142.3 MiB/s
 serpent-cbc   128b    37.9 MiB/s    39.0 MiB/s
 twofish-cbc   128b    51.2 MiB/s    52.5 MiB/s
     aes-cbc   256b   124.9 MiB/s   125.6 MiB/s
 serpent-cbc   256b    37.9 MiB/s    39.0 MiB/s
 twofish-cbc   256b    51.1 MiB/s    52.4 MiB/s
     aes-xts   256b    41.0 MiB/s    43.1 MiB/s
 serpent-xts   256b    38.7 MiB/s    38.7 MiB/s
 twofish-xts   256b    52.5 MiB/s    51.6 MiB/s
     aes-xts   512b    32.4 MiB/s    33.6 MiB/s
 serpent-xts   512b    38.7 MiB/s    38.7 MiB/s
 twofish-xts   512b    52.4 MiB/s    51.6 MiB/s
I wonder settings it's missing.

indium
Posts: 89
Joined: Thu May 28, 2015 2:27 pm
languages_spoken: english, ukrainian
Location: Ukraine
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by indium » Tue Dec 22, 2015 12:38 pm

Does anyone know what exactly "hardware acceleration" is used on xu4? is this some aes instructions of armv7 isa (yes, on my shame, I'm not aware of any "crypto" instructions of armv7), or this is some "crypto-engine" embedded in the exynos soc and it needs to be supported by the specific driver? does really that h/a happen there? or maybe those huge numbers of aes-cbc are just taken by straight code without any focuses?

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Wed Dec 23, 2015 9:39 am

I have no idea, but it varies a lot on anything not Ubuntu 15.04.

On the previous note, cryptsetup benchmark on 14.04 Ubuntu Server image is worse than Debian Jessie even with performance governor. I lost the values, but was around 200000 for sha1.

Arch Linux ARM results are even more baffling (performance governor):

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       150657 iterations per second for 256-bit key
PBKDF2-sha256     189959 iterations per second for 256-bit key
PBKDF2-sha512      52428 iterations per second for 256-bit key
PBKDF2-ripemd160  113975 iterations per second for 256-bit key
PBKDF2-whirlpool   33781 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   144.3 MiB/s   144.6 MiB/s
 serpent-cbc   128b           N/A           N/A
 twofish-cbc   128b    53.5 MiB/s    57.2 MiB/s
     aes-cbc   256b   126.7 MiB/s   127.0 MiB/s
 serpent-cbc   256b           N/A           N/A
 twofish-cbc   256b    53.4 MiB/s    57.1 MiB/s
     aes-xts   256b    63.1 MiB/s    62.3 MiB/s
 serpent-xts   256b           N/A           N/A
 twofish-xts   256b    54.0 MiB/s    56.1 MiB/s
     aes-xts   512b    51.3 MiB/s    50.6 MiB/s
 serpent-xts   512b           N/A           N/A
 twofish-xts   512b    53.9 MiB/s    56.0 MiB/s

How can sha1 be slower than sha256??

There's got to be settings missing.

(these are all with the 3.10.92 kernel, updated)

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Wed Dec 23, 2015 9:51 am

So my question now: what is Ubuntu 15.04 doing to get 400+MB/s on cbc that Debian & friends are not??

indium
Posts: 89
Joined: Thu May 28, 2015 2:27 pm
languages_spoken: english, ukrainian
Location: Ukraine
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by indium » Wed Dec 23, 2015 11:17 am

ok, to make it clearer, there is no such thing on armv7 as aes-related instructions. they appear only on armv8 and funny are commented as "not intended to replace hardware accelerators in an SoC" in the preview document. which indicates that all this is just a marketing foam (read - just because Intel has them we couldn't not to shove it into the architecture). what a "speed-up" they'll bring, is a question.
so this may be only some kind of a SoC module, very specific to the SoC and thus having need to be supported. With this you have to interface with it special way to get its 'acceleration' capability. So this approach needs specific driver from the integrator/vendor and specific API to it, which that test (or libraries it uses) should be aware of. So maybe that version of Ubuntu has this? But I haven't found any crypto-accelerators on the block scheme of exynos 5422. Unfortunately, by now I only may theoretize about this. And my guess is that there is not any acceleration of that kind over there.
Yet another possibility is that the test makes it wrong way, is glitchy and gives reproducibly crappy urealistic numbers on aes-cbc. even with some crypto-engine, it's highly doubtful to get > than x10 speed up.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Wed Dec 23, 2015 11:42 am

there is no such thing on armv7 as aes-related instructions
Good to know. I guess this means we shouldn't expect any free speedups on ssh, openssl, etc (and my ssh test and a quick openssl speed run didn't show any drastic cbc gains).

Here's result for non-server Ubuntu LTS (14.01 + dist-upgrade + kernel update):

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       208050 iterations per second
PBKDF2-sha256     129774 iterations per second
PBKDF2-sha512      38778 iterations per second
PBKDF2-ripemd160  191345 iterations per second
PBKDF2-whirlpool   29789 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   465.0 MiB/s   429.8 MiB/s
 serpent-cbc   128b    36.5 MiB/s    38.3 MiB/s
 twofish-cbc   128b    49.3 MiB/s    49.0 MiB/s
     aes-cbc   256b   429.7 MiB/s   405.9 MiB/s
 serpent-cbc   256b    38.1 MiB/s    38.9 MiB/s
 twofish-cbc   256b    49.5 MiB/s    49.5 MiB/s
     aes-xts   256b    50.9 MiB/s    45.4 MiB/s
 serpent-xts   256b    38.2 MiB/s    38.4 MiB/s
 twofish-xts   256b    50.5 MiB/s    50.0 MiB/s
     aes-xts   512b    41.3 MiB/s    37.1 MiB/s
 serpent-xts   512b    38.4 MiB/s    38.4 MiB/s
 twofish-xts   512b    50.5 MiB/s    49.8 MiB/s
On this one CBC can reach full speed but the hashing is behind 15.04 and Debian. Again this is with performance governor set in boot.ini (and X disabled). But as we can see now the issue isn't only CBC.

(personally after running all these I'd simply like to get Debian to reach 400MB/s for CBC; it's the closest to 15.04 apart from that)

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Wed Dec 23, 2015 12:12 pm

indium wrote: Yet another possibility is that the test makes it wrong way, is glitchy and gives reproducibly crappy urealistic numbers on aes-cbc. even with some crypto-engine, it's highly doubtful to get > than x10 speed up.
Possible. I've never taken this test as a gold standard. But still the relative difference between the OSes must signify something (missing).

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Thu Dec 24, 2015 6:11 am

I'm now running the Debian image again (performance gov), and finding that real transfer speeds differ significantly from benchmarks.

Here are containers created on a USB3 drive and dd speed (note there is a slight buffer time before sync, but not significant)

Code: Select all

# plain ext4
dd if=/dev/zero of=temp.bin bs=4M count=1000; sync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 52.344 s, 80.1 MB/s

cryptsetup luksFormat --cipher aes-cbc-essiv:sha256 -h sha512 -s 128 --iter-time 10000 /dev/sda1
dd if=/dev/zero of=temp.bin bs=4M count=1000; sync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 215.951 s, 19.4 MB/s

cryptsetup luksFormat --cipher aes-cbc-essiv:sha256 -h sha512 -s 256, with ext4
dd if=/dev/zero of=temp.bin bs=4M count=1000; sync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 218.901 s, 19.2 MB/s

(aes-cbc-plain is about the same as essiv, lost numbers)

# note this is actually 128 bits (xts 256/2)
cryptsetup luksFormat --cipher aes-xts-plain-64 -h sha512 -s 256, with ext4
dd if=/dev/zero of=temp.bin bs=4M count=1000; sync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 217.376 s, 19.3 MB/s

cryptsetup luksFormat --cipher twofish-cbc-essiv:sha256 -h sha512 -s 256, with ext4
dd if=/dev/zero of=temp.bin bs=4M count=1000; sync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 90.4243 s, 46.4 MB/s

# note this is actually 128 bits (xts 256/2)
cryptsetup luksFormat --cipher twofish-xts-plain-64 -h sha512 -s 256, with ext4
dd if=/dev/zero of=temp.bin bs=4M count=1000; sync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 90.1085 s, 46.5 MB/s

# note this is actually 256 bits (xts 512/2)
cryptsetup luksFormat --cipher twofish-xts-plain-64 -h sha512 -s 512, with ext4
dd if=/dev/zero of=temp.bin bs=4M count=1000; sync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 78.9833 s, 53.1 MB/s

# note this is actually 256 bits (xts 512/2)
cryptsetup luksFormat --cipher serpent-xts-plain-64 -h sha512 -s 512, with ext4
dd if=/dev/zero of=temp.bin bs=4M count=1000; sync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 78.7893 s, 53.2 MB/s
AES performance is inexplicably poor across the board, opposite of benchmark. For reference, my Atom gets 27MB/s AES256 on an external disk even though benchmark shows it's its worst cipher. XU4 is capped at 20MB/s.

Twofish performance is decent (better than my Atom on its best strong cipher and internal disk) and Serpent is better than benchmark. Too bad they left it out of Arch.

I don't fully understand these results.

I didn't try ubuntu 16.04 yet as meveric suggested. I'd like to try AES on Ubuntu to see if it has this same issue, but I need to find another card.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Thu Dec 24, 2015 1:52 pm

Here's a script to benchmark on a real disk [WRITE ONLY]. Automated version of above.

Code: Select all

SRCDEV=/dev/sda1
TESTKEY=/tmp/testkey.key
PASSHASH=sha512
FILEBLOCKSIZE=4M
FILEBLOCKCOUNT=1000

read -p "THIS WILL DESTROY $TESTKEY AND $SRCDEV. PRESS ANY KEY TO START..."

dd if=/dev/urandom of="$TESTKEY" bs=512 count=1 ; sync

test_cipher()
{
  local cipher="$1"
  local keysize="$2"
  echo ""
  echo "$cipher ($keysize bit key)"
  cryptsetup luksFormat -q -d "$TESTKEY" --cipher $cipher -h $PASSHASH -s $keysize "$SRCDEV" && sync && \
  cryptsetup open -q -d "$TESTKEY" "$SRCDEV" test && mkfs.ext4 -q /dev/mapper/test && sync && mount /dev/mapper/test /mnt && cd /mnt && \
    dd if=/dev/zero of=temp.bin bs=$FILEBLOCKSIZE count=$FILEBLOCKCOUNT && sync && \
    cd / && umount /mnt && cryptsetup close -q /dev/mapper/test && sync
}

test_cipher aes-cbc-essiv:sha256 128 && \
test_cipher aes-cbc-essiv:sha256 256 && \
test_cipher aes-xts-plain64 256 && \
test_cipher aes-xts-plain64 512 && \
test_cipher twofish-cbc-essiv:sha256 128 && \
test_cipher twofish-cbc-essiv:sha256 256 && \
test_cipher twofish-xts-plain64 256 && \
test_cipher twofish-xts-plain64 512 && \
test_cipher serpent-cbc-essiv:sha256 128 && \
test_cipher serpent-cbc-essiv:sha256 256 && \
test_cipher serpent-xts-plain64 256 && \
test_cipher serpent-xts-plain64 512 && \
  true || echo "ERROR"



Here are more script run results (on USB3 drive):

Ubuntu 15.04

Code: Select all

aes-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 212.688 s, 19.7 MB/s

aes-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 212.422 s, 19.7 MB/s

aes-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 209.988 s, 20.0 MB/s

aes-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 225.778 s, 18.6 MB/s

twofish-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 94.8641 s, 44.2 MB/s

twofish-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 85.3068 s, 49.2 MB/s

twofish-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 83.2676 s, 50.4 MB/s

twofish-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 82.2277 s, 51.0 MB/s

serpent-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 77.5473 s, 54.1 MB/s

serpent-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 79.4386 s, 52.8 MB/s

serpent-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 77.8704 s, 53.9 MB/s

serpent-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 80.5299 s, 52.1 MB/s
Debian Jessie (full run)

Code: Select all

aes-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 211.543 s, 19.8 MB/s

aes-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 212.335 s, 19.8 MB/s

aes-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 207.108 s, 20.3 MB/s

aes-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 216.893 s, 19.3 MB/s

twofish-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 92.1838 s, 45.5 MB/s

twofish-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 85.1948 s, 49.2 MB/s

twofish-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 80.4026 s, 52.2 MB/s

twofish-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 84.2072 s, 49.8 MB/s

serpent-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 76.6262 s, 54.7 MB/s

serpent-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 76.8243 s, 54.6 MB/s

serpent-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 78.8069 s, 53.2 MB/s

serpent-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 77.8578 s, 53.9 MB/s
Nearly identical.

AES on XU4 kernel 3.10 is unexpectedly poor. Less than half of Twofish and Serpent. Maybe there's a driver/module or threading/cores issue, beside or related to the high "fake" benchmark.

Twofish and Serpent are good. Serpent is slightly faster despite slower on paper (cryptsetup benchmark).

Haven't tried 16.04 yet. Or any kernel past 3.10.92+.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Thu Dec 24, 2015 4:13 pm

I compiled kernel 4.2.0-rc1+ on Ubuntu 15.04. cryptsetup benchmark fails, and is missing twofish and other ciphers, but nevertheless:

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       313944 iterations per second
PBKDF2-sha256     201649 iterations per second
PBKDF2-sha512     128501 iterations per second
PBKDF2-ripemd160  242725 iterations per second
PBKDF2-whirlpool   31356 iterations per second
Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded.
But now look at these real disk results:

Code: Select all

aes-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 59.3515 s, 70.7 MB/s

aes-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 50.5675 s, 82.9 MB/s

aes-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 58.6947 s, 71.5 MB/s

aes-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 50.9715 s, 82.3 MB/s
AES is the only working cipher here, but it saturates disk speed (80MB/s) and easily beats all the other ciphers. The slow AES problem clearly fixed with 4.2 kernel.

So there is a major performance problem with AES on the 3.10 kernel, in addition to the "cryptsetup benchmark" anomalies in non-Ubuntu images.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Fri Dec 25, 2015 6:30 am

examining the kernel 4.2 rc1 configs with make menuconfig:
kernel42aesaccel.png
(64.02 KiB) Downloaded 3003 times
It's also enabled in the 3.10.92 kernel but in the parent menu. The only difference is 3.10 doesn't seem to have the SHA224+ ARM-asm modules. But I'm not sure if that should make a difference or not (in aes-cbc-plain and aes-xts-plain-64, which were slow).

Worth noting my compile for 4.2 was missing a bunch of crypto modules that are in fact enabled in 3.10, so I wonder if possibly one of the modules enabled in 3.10 is interfering with ARM-asm accel.

indium
Posts: 89
Joined: Thu May 28, 2015 2:27 pm
languages_spoken: english, ukrainian
Location: Ukraine
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by indium » Fri Dec 25, 2015 7:15 am

Funny name - "arm accelerated algorithms". It seems it is just a hand written arm assembly language implemetation of the algorithms. With using NEON SIMD for the hash functions. This is kind of an ordinary way of implementing all that crypto thing.
Anyway, those wierd numbers in the crypto setup benchmark uncover some problems of the test by itself, not any supposed "acceleration" which as It's seen now, doesn't exist.

PS. Personally, I'm glad that these are plain implementation in arm, without that quasi-acceleration, because I don't believe it. My interest was because of those high numbers, i couldn't believe the vaporware "acceleration" might give that. And, as it turned, my suspections was truth - the numbers are fake. In the end, XU4 has a comparable crypt performance to Atom chips. But again, xu4's SoC is highly multiprocessor, and how fully the underlying test code was taking advantage of it, is unknown. I mean, maybe the test did not use all 8 cores as it might, and if it did - it might gain higher numbers. I suspect many programs on linux are not taking full advantage of multiprocessing. But I'm biased of course.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Fri Dec 25, 2015 9:12 am

Minor update: The AES performance issue appears unrelated to the SHA224/256 acceleration exclusive to 4.2 kernel. I compiled the 4.2 kernel without ARM-asm SHA256 opt and the disk write bench still comes out 70-80MB/s.

From the little I can see the ARM-asm SHA256 seems only marginally faster.

So I have no idea as to why the 3.10 kernel AES is practically unusable. I think reasonably there's nothing more I can try without more hints from someone more knowledgeable.

I'm thinking 3.10 is a lost cause. There's enough in the 4.x line to want it. Going from nearly-unusable AES speed to excellent speed is huge (unless someone else can fix it in 3.10).

Debian's another matter.
It seems it is just a hand written arm assembly language implemetation of the algorithms
Yep. I could try to recompile without ARM-asm AES module to confirm its contribution in numbers but obviously in the end you want it enabled, so probably waste of time.
In the end, XU4 has a comparable crypt performance to Atom chips
Yep. Based on the real disk write performance of Twofish and Serpent, the XU4 is 60% faster for writes than my atom in practice. But this atom has a few years on it.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Fri Dec 25, 2015 1:24 pm

So I was trying to test a 4.2 kernel quicly for my own purposes and enabled a bunch of crypto modules.

The cryptsetup benchmark came out atrociously low:

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       117028 iterations per second
PBKDF2-sha256      82956 iterations per second
PBKDF2-sha512      38102 iterations per second
PBKDF2-ripemd160  109226 iterations per second
PBKDF2-whirlpool    9375 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    25.0 MiB/s    27.7 MiB/s
 serpent-cbc   128b    14.7 MiB/s    17.0 MiB/s
 twofish-cbc   128b    23.5 MiB/s    26.1 MiB/s
     aes-cbc   256b    21.0 MiB/s    22.3 MiB/s
 serpent-cbc   256b    15.4 MiB/s    17.2 MiB/s
 twofish-cbc   256b    24.4 MiB/s    26.5 MiB/s
     aes-xts   256b    29.7 MiB/s    29.1 MiB/s
 serpent-xts   256b    16.3 MiB/s    17.5 MiB/s
 twofish-xts   256b    27.5 MiB/s    27.2 MiB/s
     aes-xts   512b    23.3 MiB/s    23.1 MiB/s
 serpent-xts   512b    16.3 MiB/s    17.6 MiB/s
 twofish-xts   512b    27.3 MiB/s    27.1 MiB/s
I must have done something wrong. Then I ran a disk write test:

Code: Select all

aes-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 64.3631 s, 65.2 MB/s

aes-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 56.6843 s, 74.0 MB/s

aes-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 64.9719 s, 64.6 MB/s

aes-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 55.0143 s, 76.2 MB/s

twofish-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 58.3345 s, 71.9 MB/s

twofish-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 64.0153 s, 65.5 MB/s

twofish-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 62.3003 s, 67.3 MB/s

twofish-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 59.3445 s, 70.7 MB/s

serpent-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 48.318 s, 86.8 MB/s

serpent-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 46.6205 s, 90.0 MB/s

serpent-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 48.6781 s, 86.2 MB/s

serpent-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 50.2428 s, 83.5 MB/s
Somehow I lowered AES to 60-70MB/s.

But Serpent reaches 90MB/s!

Somewhere in 4.2 kernel is a magic potion for super fast ARM crypto.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Fri Dec 25, 2015 2:18 pm

Low numbers in post above seem to be because either an extra reboot is needed or need to reinstall cryptsetup after kernel deploy, not sure which.

Here are corrected numbers after doing that, looks saner:

Code: Select all

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       313944 iterations per second
PBKDF2-sha256     200109 iterations per second
PBKDF2-sha512     127254 iterations per second
PBKDF2-ripemd160  242725 iterations per second
PBKDF2-whirlpool   30481 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    62.7 MiB/s    64.4 MiB/s
 serpent-cbc   128b    41.6 MiB/s    43.3 MiB/s
 twofish-cbc   128b    58.0 MiB/s    60.4 MiB/s
     aes-cbc   256b    49.3 MiB/s    50.2 MiB/s
 serpent-cbc   256b    40.8 MiB/s    42.4 MiB/s
 twofish-cbc   256b    57.4 MiB/s    59.7 MiB/s
     aes-xts   256b    69.0 MiB/s    68.7 MiB/s
 serpent-xts   256b    42.0 MiB/s    42.8 MiB/s
 twofish-xts   256b    58.7 MiB/s    59.1 MiB/s
     aes-xts   512b    50.7 MiB/s    50.5 MiB/s
 serpent-xts   512b    40.2 MiB/s    41.2 MiB/s
 twofish-xts   512b    58.4 MiB/s    59.4 MiB/s
This benchmark is much more realistic, even pessimistic. Write speeds are good:

Code: Select all

aes-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 58.1813 s, 72.1 MB/s

aes-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 50.2148 s, 83.5 MB/s

aes-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 56.6054 s, 74.1 MB/s

aes-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 50.3853 s, 83.2 MB/s

twofish-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 61.1171 s, 68.6 MB/s

twofish-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 60.8124 s, 69.0 MB/s

twofish-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 59.338 s, 70.7 MB/s

twofish-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 61.2366 s, 68.5 MB/s

serpent-cbc-essiv:sha256 (128 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 46.8704 s, 89.5 MB/s

serpent-cbc-essiv:sha256 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 49.2536 s, 85.2 MB/s

serpent-xts-plain64 (256 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 49.829 s, 84.2 MB/s

serpent-xts-plain64 (512 bit key)
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 47.4999 s, 88.3 MB/s
It's looking as though despite AES having ARM-asm optimizations, it gets beaten out by Serpent! At least in writes.

Now benchmarking is problematic because the ciphers sometimes saturate the drive write speed! I should test in tmpfs, but I worry about skewed results there. dd is maybe not the best...

I should point out that Serpent was also the fastest cipher on the Atom. So it's starting to line up...

I should also point out that in this kernel compile I have a lot of crypto kernel modules still disabled, such as "parallel crypto engine" (which doesn't seem to help the 3.10 kernel at all).

It's a lot of work, but look at these speeds compared to the 3.10 kernel!

indium
Posts: 89
Joined: Thu May 28, 2015 2:27 pm
languages_spoken: english, ukrainian
Location: Ukraine
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by indium » Fri Dec 25, 2015 2:20 pm

Ok, I have looked at the source files of cryptsetup benchmark (thankfully the are pretty straightforward), and may say, that those huge numbers on aes may come from the inaccuracy of the test's calculations.
For those who wants to dig deeper, the files of interest are https://gitlab.com/cryptsetup/cryptsetu ... yptsetup.c
and https://gitlab.com/cryptsetup/cryptsetu ... enchmark.c

the code has some lower limit on the time spent on encoding/decoding 1MB buffer at once - 0.001 ms, and if this threshold is reached, code considers results unreliable and increases the input buffer doubling it and retries. But what if the time would be only somewhat higher than this limit? Then the code would count such results normal, however they are only slightly better than inaccpetable by the test itself. I mean this hard limit imposed here by the test is clearly a point of inaccuracy. It looks like aes may experience this problem. I don't know why a too low time is considered unreliable, maybe because of inaccuracy of timers, but if the cipher makes its job fast it generates the biggest number of passes inside the test imposed 1000 ms range and every pass will have the highest time inaccuracy resulting in overall highest inaccuracy. The only question is whether this factor may give such an increase as seen. And this weird difference between Ubuntu and others then may be a matter of the timer accuracy used inside clock_gettime() function.
Last edited by indium on Fri Dec 25, 2015 2:27 pm, edited 1 time in total.

indium
Posts: 89
Joined: Thu May 28, 2015 2:27 pm
languages_spoken: english, ukrainian
Location: Ukraine
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by indium » Fri Dec 25, 2015 2:25 pm

It's looking as though despite AES having ARM-asm optimizations, it gets beaten out by Serpent! At least in writes
No one takes assembler from Serpent implementers' hands. :) I think all cryptographic core algorithms are implemeted this way, and so with Serpent.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Fri Dec 25, 2015 4:29 pm

You're right, the test looks dodgy.

Here's another script that dd's files in tmpfs or disk (tmpfs by default, requires 1G /tmp; pass "/dev/sda1" on command line for non-tmpfs), does WRITE + READ and flushing on dd writes and 8M buffer instead of 4M (so don't compare to previous results except for vague idea):

Code: Select all

#!/bin/bash

echo "Cryptsetup disk benchmark script"

# Default settings assume a 1G tmpfs is mount at /tmp and mostly unused
# add this to /etc/fstab and reboot:
#tmpfs /tmp tmpfs nodev,nosuid,size=1G 0 0
# Alternatively, change SRCDEV to an existing disk.

SRCDEV="$1"
if [[ -z "$SRCDEV" ]]; then
  #SRCDEV=/dev/sda1
  SRCDEV=/tmp/testcontainer.bin
fi
SRCDEVSIZE=939524096
TESTKEY=/tmp/testkey.key
TESTKEYSIZE=512
PASSHASH=sha512
FILEBLOCKSIZE=8M
FILEBLOCKCOUNT=100
CRYPTDEVNAME=test
MOUNTPOINT=/mnt
# conv=fsync causes write test to flush more often but less intelligently
DDWRITEEXTRACMDS="conv=fsync"
DDREADEXTRACMDS=""

if [[ "$USER" != "root" ]]; then
  echo "Must be root"
  exit 1
fi

echo "Device: $SRCDEV ; Keyfile: $TESTKEY"
read -p "PRESS ANY KEY TO START..."

if [[ ! -e "$SRCDEV" ]]; then
  fallocate -l $SRCDEVSIZE "$SRCDEV" || { echo "ERROR allocating"; exit 1; }
fi

if [[ ! -e "$TESTKEY" ]]; then
  dd if=/dev/urandom of="$TESTKEY" bs=${TESTKEYSIZE} count=1 ; sync || { echo "ERROR making key"; exit 1; }
fi

if [[ ! -d "$MOUNTPOINT" ]]; then
  mkdir -p "$MOUNTPOINT" || { echo "ERROR making mount point"; exit 1; }
fi

clear_caches()
{
  sync
  echo 3 > /proc/sys/vm/drop_caches
  sync
}

test_cipher()
{
  local cipher="$1"
  local keysize="$2"
  echo ""
  echo "$cipher ($keysize bit key)"
  cryptsetup luksFormat -q -d "$TESTKEY" --cipher $cipher -h $PASSHASH -s $keysize "$SRCDEV" && sync && \
  cryptsetup open -q -d "$TESTKEY" "$SRCDEV" ${CRYPTDEVNAME} && mkfs.ext4 -q /dev/mapper/${CRYPTDEVNAME} && sync && mount /dev/mapper/${CRYPTDEVNAME} "$MOUNTPOINT" && cd "$MOUNTPOINT" && clear_caches && \
    echo "WRITE:" && dd ${DDWRITEEXTRACMDS} if=/dev/zero of=temp.bin bs=$FILEBLOCKSIZE count=$FILEBLOCKCOUNT && clear_caches && 
    echo "READ:" && dd ${DDREADEXTRACMDS} if=temp.bin of=/dev/null bs=$FILEBLOCKSIZE count=$FILEBLOCKCOUNT && clear_caches && \
    cd / && umount "$MOUNTPOINT" && cryptsetup close -q ${CRYPTDEVNAME} && sync
}

control_c()
{
  cd /
  sync
  if mount | grep -qP "^/dev/mapper/${CRYPTDEVNAME}\\s"; then
    echo "Unmounting..."
    umount "$MOUNTPOINT"
  fi
  sync
  if [[ -e "/dev/mapper/${CRYPTDEVNAME}" ]]; then
    echo "Closing crypt device..."
    cryptsetup close ${CRYPTDEVNAME}
  fi
  exit 0
}
 
trap control_c EXIT

test_cipher aes-cbc-essiv:sha256 128 && \
test_cipher aes-cbc-essiv:sha256 256 && \
test_cipher aes-xts-plain64 256 && \
test_cipher aes-xts-plain64 512 && \
test_cipher twofish-cbc-essiv:sha256 128 && \
test_cipher twofish-cbc-essiv:sha256 256 && \
test_cipher twofish-xts-plain64 256 && \
test_cipher twofish-xts-plain64 512 && \
test_cipher serpent-cbc-essiv:sha256 128 && \
test_cipher serpent-cbc-essiv:sha256 256 && \
test_cipher serpent-xts-plain64 256 && \
test_cipher serpent-xts-plain64 512 && \
  true || { echo "ERROR in test"; exit 1; }
  
exit 0

Here are the tmpfs results from my last kernel compile [4.2 rc1, Ubuntu 15.04]:

Code: Select all

Device: /tmp/testcontainer.bin ; Keyfile: /tmp/testkey.key
PRESS ANY KEY TO START...

aes-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 13.4743 s, 62.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 12.8426 s, 65.3 MB/s

aes-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 11.1417 s, 75.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 12.6961 s, 66.1 MB/s

aes-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 13.087 s, 64.1 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 15.4519 s, 54.3 MB/s

aes-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 11.1919 s, 75.0 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 14.9536 s, 56.1 MB/s

twofish-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 13.5836 s, 61.8 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 12.43 s, 67.5 MB/s

twofish-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 13.4615 s, 62.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 16.8836 s, 49.7 MB/s

twofish-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 13.808 s, 60.8 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 17.0978 s, 49.1 MB/s

twofish-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 14.999 s, 55.9 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 15.3249 s, 54.7 MB/s

serpent-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 10.7088 s, 78.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 12.672 s, 66.2 MB/s

serpent-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 9.97456 s, 84.1 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 22.5867 s, 37.1 MB/s

serpent-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 9.82584 s, 85.4 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 19.4767 s, 43.1 MB/s

serpent-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 10.184 s, 82.4 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 13.6009 s, 61.7 MB/s

Now disk results again [4.2 rc1, Ubuntu 15.04]:

Code: Select all

Device: /dev/sda1 ; Keyfile: /tmp/testkey.key
PRESS ANY KEY TO START...

aes-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 11.2188 s, 74.8 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 19.8854 s, 42.2 MB/s

aes-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 10.5814 s, 79.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 21.6841 s, 38.7 MB/s

aes-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 12.2692 s, 68.4 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 18.8764 s, 44.4 MB/s

aes-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 10.724 s, 78.2 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 20.5474 s, 40.8 MB/s

twofish-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 12.2961 s, 68.2 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 15.4259 s, 54.4 MB/s

twofish-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 12.7134 s, 66.0 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 17.3917 s, 48.2 MB/s

twofish-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 13.7587 s, 61.0 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 15.0272 s, 55.8 MB/s

twofish-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 12.8118 s, 65.5 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 17.0534 s, 49.2 MB/s

serpent-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 9.57162 s, 87.6 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 19.8546 s, 42.3 MB/s

serpent-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 10.7578 s, 78.0 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 24.4242 s, 34.3 MB/s

serpent-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 9.88086 s, 84.9 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 25.1674 s, 33.3 MB/s

serpent-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 9.92133 s, 84.6 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 20.0208 s, 41.9 MB/s
tmpfs seems sensitive to the dd buffer size, which is why I increased from 4M to 8M, though reads are sometimes slower at 8M. Possibly affected by "conv=fsync" also. RAM? Not as reliable as disk benchmark.

Disk writes registering faster than tmpfs writes. ?

Read speeds from disk are low, wasn't expecting. Maybe it's the USB or the disk itself, but it also varies by cipher. From tmps varies a lot by cipher. There are a few patterns I recognize, but overall read speeds are lower.

So this is flawed but still should give a better idea than "cryptsetup benchmark".

(not going to bother benching 3.10 again unless someone has a solution)

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Fri Dec 25, 2015 7:10 pm

I know I just said I wouldn't, but here are the disk bench for Debian Jessie 3.10.92+ kernel using the script above:

Code: Select all

Device: /dev/sda1 ; Keyfile: /tmp/testkey.key
PRESS ANY KEY TO START...
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000746372 s, 686 kB/s

aes-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 45.1272 s, 18.6 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 45.0868 s, 18.6 MB/s

aes-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 42.9233 s, 19.5 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 42.1385 s, 19.9 MB/s

aes-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 44.379 s, 18.9 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 43.2708 s, 19.4 MB/s

aes-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 45.9228 s, 18.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 49.1195 s, 17.1 MB/s

twofish-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 23.5674 s, 35.6 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 29.323 s, 28.6 MB/s

twofish-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 25.3697 s, 33.1 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 28.9414 s, 29.0 MB/s

twofish-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 22.9597 s, 36.5 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 28.1633 s, 29.8 MB/s

twofish-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 23.4032 s, 35.8 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 28.3025 s, 29.6 MB/s

serpent-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 21.8745 s, 38.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 32.6656 s, 25.7 MB/s

serpent-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 23.1216 s, 36.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 33.1438 s, 25.3 MB/s

serpent-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 22.8909 s, 36.6 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 33.059 s, 25.4 MB/s

serpent-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 22.5162 s, 37.3 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 33.0944 s, 25.3 MB/s

I can't believe the difference.

[and here's tmpfs, clearly faster than disk on 3.10:]

Code: Select all

Device: /tmp/testcontainer.bin ; Keyfile: /tmp/testkey.key
PRESS ANY KEY TO START...
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000799414 s, 640 kB/s

aes-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 40.2936 s, 20.8 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 30.2047 s, 27.8 MB/s

aes-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 39.5492 s, 21.2 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 32.3276 s, 25.9 MB/s

aes-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 40.3386 s, 20.8 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 30.6017 s, 27.4 MB/s

aes-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 40.3732 s, 20.8 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 35.456 s, 23.7 MB/s

twofish-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 15.4899 s, 54.2 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 22.7198 s, 36.9 MB/s

twofish-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 16.7901 s, 50.0 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 22.7199 s, 36.9 MB/s

twofish-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 15.9601 s, 52.6 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 23.1515 s, 36.2 MB/s

twofish-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 15.8436 s, 52.9 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 23.0767 s, 36.4 MB/s

serpent-cbc-essiv:sha256 (128 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 17.0684 s, 49.1 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 29.7162 s, 28.2 MB/s

serpent-cbc-essiv:sha256 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 17.3033 s, 48.5 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 29.6547 s, 28.3 MB/s

serpent-xts-plain64 (256 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 17.8541 s, 47.0 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 29.8918 s, 28.1 MB/s

serpent-xts-plain64 (512 bit key)
WRITE:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 17.1378 s, 48.9 MB/s
READ:
100+0 records in
100+0 records out
838860800 bytes (839 MB) copied, 30.0166 s, 27.9 MB/s
Last edited by sha256 on Sat Dec 26, 2015 1:20 pm, edited 1 time in total.

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Sat Dec 26, 2015 9:43 am

I installed my modified 4.2rc1 kernel (all crypto modules enabled this time) into meveric's Debian Jessie image.

It produces a "cryptsetup benchmark" same as Ubuntu 15.04 with 4.2rc1 posted above.

But for some reason luksFormat causes a total sys lockup for some ciphers. No-go. [update: apparently an issue with initramfs? somehow got it to work just now, don't know how; anyhow write results slightly slower than ubuntu 15.04]

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Tue Dec 29, 2015 12:35 pm

So after all this (and some other benches not posted) I came to the conclusion that Twofish is probably the best cipher to use on any kernel. Although it gets beat out in write speeds, it has consistent read speeds that are often higher than the others on average for disk (tmpfs says otherwise, but it's too unpredictable), and read tends to be more important for most use.

I notice in general on non-Intel or older platforms Twofish tends to do well, while on Intels often Serpent or AES when accelerated can be much faster.

Write and read speeds are inverted compared to the Atom, where usually read is faster than write. Don't know why write is so much faster than read on odroids (could be multi-core ARMs in general but can't test on others at this time). Maybe my bench is flawed, but the same script on Atom gives read faster than write.

As long as you have to use the 3.10 kernel you're losing at least 15-20MB/s on read and write on all ciphers, and AES is too poor for serious use. Problem is 4.2 kernel is unsupported (no recent updates) so while I've compiled it to look at prospects, not a good option if security matters. Haven't tried to compile vanilla 4.4 like I see others doing.

The fastest 3.10 performance seems to be on Arch and Ubuntu 15.04, with Arch slightly faster for Twofish. But Arch odroid kernel is built without Serpent (and some other modules I bet, haven't checked). But the difference is minor; 3.10 is what holds everything back. If I had to pick something now it would have to be Arch with drives recrypted with Twofish, but I think I will just delay using this odroid for serious purpose for now.

stmicro
Posts: 236
Joined: Tue Apr 28, 2015 4:23 pm
languages_spoken: english, chinese
ODROIDs: Many Odroids and Rpis.
Location: shenzhen china
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by stmicro » Tue Dec 29, 2015 2:01 pm

Thank you for sharing the intensive tests even there is no clear conclusion yet.
Can you tell me what is your serious purpose on this small ARM board? Encrypted file system for the secure server?
I've daily used it for a media center, gaming and web browsing. It is not a serious usage case at all. ;)

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Tue Dec 29, 2015 3:04 pm

Yes it's for use as lower-power headless server with encryption on all connections. Typically 2 encrypted disks, vpn and ssl connections or equivalents for 1-2 net services (obviously not running amazon.com here), and 1-3 ssh connections at a time. File transfers. Disk setup not too professional but the rest is tightened.

The Atom had trouble keeping up with that setup. I think the XU4 should be able if optimized properly, but from experience 20MB/s disk encryption (AES) is too low after you add in everything else, take up the CPU and drag it down. The unknown is how far the usage of cores/threading goes, since XU4 has 4-8 cores, might it alleviate that shortcoming - the Atom was only dual-core. I still have to benchmark other parts and the whole, but may wait.

The Atom did not have USB3 or gigabit. Their transfer rates are working great on the XU4 so it removes those bottlenecks (which you hit on USB2 and 100Mbps ethernet with multiple drives and connections).

Whole list of reasons the XU4 makes sense, some very circumstantial.

Catscrash
Posts: 39
Joined: Tue Mar 26, 2013 9:45 pm
languages_spoken: english, german
ODROIDs: Odroid U2
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by Catscrash » Tue Jan 12, 2016 6:12 pm

can one of you, who has those nice real values, send me your .config for the 4.2 kernel?

Thanks!

sha256
Posts: 51
Joined: Sat Dec 12, 2015 8:01 am
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by sha256 » Wed Jan 13, 2016 1:48 pm

The last .config file I compiled with is attached. I'm not sure which of the above it corresponds to because this was two weeks ago and I wiped my card.

If you want to make sure you get the correct one, follow:
http://odroid.com/dokuwiki/doku.php?id= ... ing_kernel
...
make odroidxu4_defconfig
make menuconfig
and select all the Cryptographic API manually as built-in or modules, then take the .config.

-------------------

I might as well give more feedback. I tried running a file server with no load and moderate load on Arch and kernel 3.10 and Twofish crypt (so max 29MBytes/s read).

The max SSH (chacha-poly, which had transfer of 55-60MBytes/s alone) transfer speed from the disk was 17-19MBytes/s with no other loads. Transfer speed over basic nginx SSL/TLS (don't know cipher) from disk was max 24-25MBytes/s with no other loads. Can't bench VPN.

With simultaneous loads it could run for a while serving a bit below Ethernet speed but frequently crippled. It comes out much faster than the old Atom but still has trouble under heavy loads. The disk crypt is obviously a bottleneck on 3.10.

I ran out of time to invest.
Attachments
config-4.2-maybe-cryptmodules.7z
(20.27 KiB) Downloaded 98 times

ard
Posts: 72
Joined: Tue Jul 09, 2013 2:12 am
languages_spoken: english, dutch, german
ODROIDs: ODROID-U2
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by ard » Sat Jan 16, 2016 12:24 am

Is there a reason that you do not use the samsung aes encryption engine? Or is it just not possible?
I know openssl and such cannot use it unless you patch it to use the kernel crypto api.
But in kernel you should just select the samsung ACE for the encryption part.

elatllat
Posts: 1136
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by elatllat » Sat Jan 16, 2016 5:57 am

ard wrote:Is there a reason that you do not use the samsung aes encryption engine? Or is it just not possible?
I know openssl and such cannot use it unless you patch it to use the kernel crypto api.
But in kernel you should just select the samsung ACE for the encryption part.
I'm aware of the AES instruction set but that's not supported by this CPU;

Code: Select all

cat /proc/cpuinfo | grep Features | head -n 1
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
Have any links to documentation on whatever you are referring to?

indium
Posts: 89
Joined: Thu May 28, 2015 2:27 pm
languages_spoken: english, ukrainian
Location: Ukraine
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by indium » Sat Jan 16, 2016 7:23 am

there is no AES (and other) cryptographics related instructions in the armv7 ISA which xu4's SoC's CPUs belong to.
Speaking of some kind of "offloading engine" on the SoC, a question to ard, are you sure Exynos 5422 has such an "engine"?

eldon
Posts: 3
Joined: Sun Jan 10, 2016 7:40 pm
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by eldon » Mon Dec 05, 2016 10:05 pm

could someone please post a raw openssl benchmark (openvpn oriented) for the xu4

> sudo openssl speed -elapsed -evp bf-cbc aes-128-cbc

i don't really need other ciphers but if you want you can do a full range adding aes-256-cbc and so on, see "openssl help" for the full list

thank you.

User avatar
meveric
Posts: 9680
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by meveric » Mon Dec 05, 2016 10:08 pm

Debian Jessie:

Code: Select all

$ openssl speed -elapsed -evp bf-cbc aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 15803754 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 4241383 aes-128 cbc's in 3.01s
Doing aes-128 cbc for 3s on 256 size blocks: 1103102 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 278519 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 34674 aes-128 cbc's in 3.00s
Doing bf-cbc for 3s on 16 size blocks: 8839369 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 64 size blocks: 2451075 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 256 size blocks: 646029 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 1024 size blocks: 161326 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 8192 size blocks: 20288 bf-cbc's in 3.00s
OpenSSL 1.0.1t  3 May 2016
built on: Fri Sep 23 19:23:52 2016
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      84286.69k    90182.23k    94131.37k    95067.82k    94683.14k
bf-cbc           47143.30k    52289.60k    55127.81k    55065.94k    55399.77k
Ubuntu 14.04:

Code: Select all

$ openssl speed -elapsed -evp bf-cbc aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 16230500 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 4285272 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 1107846 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 278925 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 34944 aes-128 cbc's in 3.00s
Doing bf-cbc for 3s on 16 size blocks: 9257923 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 64 size blocks: 2665755 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 256 size blocks: 691177 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 1024 size blocks: 174554 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 8192 size blocks: 21859 bf-cbc's in 3.00s
OpenSSL 1.0.1f 6 Jan 2014
built on: Fri Sep 23 12:23:37 UTC 2016
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) 
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -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 -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      86562.67k    91419.14k    94536.19k    95206.40k    95420.42k
bf-cbc           49375.59k    56869.44k    58980.44k    59581.10k    59689.64k
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

eldon
Posts: 3
Joined: Sun Jan 10, 2016 7:40 pm
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by eldon » Mon Dec 05, 2016 11:04 pm

thx meveric for the quick reply.

Strangely enough this is less impressive than what i was expecting, about 2x-1.5x what i get on a s905 for aes-128.
Considering that real life openvpn tests show that i can barely reach 70Mbps on a s905, i would still be quite far from my max bandwidth.

USB3 would still be quite useful to saturate the gigabit link, i'll try to check if there are some bus limitations there.
I've read that one the XU4 vs XU3 "pros" is "better USB3 stability", which did not give me a great deal of confidence regarding those peripherals..

thx again

User avatar
meveric
Posts: 9680
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by meveric » Tue Dec 06, 2016 12:57 am

eldon wrote:thx meveric for the quick reply.

Strangely enough this is less impressive than what i was expecting, about 2x-1.5x what i get on a s905 for aes-128.
well I guess generally arm64 is a little better in handling these things, that's why C2 is still rather good compared to the XU4, even if the XU4 is still somewhat faster.
eldon wrote:USB3 would still be quite useful to saturate the gigabit link, i'll try to check if there are some bus limitations there.
I've read that one the XU4 vs XU3 "pros" is "better USB3 stability", which did not give me a great deal of confidence regarding those peripherals..

thx again
Not sure about the stability issue (never had issues on my XU3s) but on the XU4 the Gb LAN is powered by one USB 3.0 BUS, while the two USB 3.0 ports on the XU4 are sharing the other USB 3.0 BUS, while on the XU3 you have each USB BUS separated, for one USB 3.0 port, means if you want to use two HDD over USB 3.0 they are faster on the XU3 than on the XU4 since they don't share the same USB BUS.
(But then again, you have the slower network on the XU3)
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

eldon
Posts: 3
Joined: Sun Jan 10, 2016 7:40 pm
languages_spoken: english
Contact:

Re: What are your cryptsetup benchmark results on your ODROI

Unread post by eldon » Tue Dec 06, 2016 1:47 am

oh right, i somehow misread the specs believing that it was a 64bit cpu, i think i mixed up a15 and a53, but having 64bit and 32bit cores does not make sense i guess..

Yes i did see the usb3 hub on the block diagram, it's not ideal but network wise it would not make a difference, Gigabit will be the bottleneck, not the shared usb3 host.

thx for you comments, i'll see if i stay with my C2 or switch to the xu4.

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: No registered users and 1 guest