CPU-Benchmarks per OpenSSL

[Yamagi]

Untermauern wir das ganze mal mit Zahlen:

Ich habe hier ein FreeBSD 9.0 mit einem Core i7 2600k (das ist an sich irrelevant, da die AES-NI Module der Sandy Bridge Prozessoren unabhängig vom Modul in etwa gleich schnell sind. Darin ist eine 2TB Festplatte mit 5900 Umdrehungen, darauf ein GELI mit AES-256-XTS über AES-NI beschleunigt:

GEOM_ELI: Device ada1p2.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: hardware

Nimmt man das AES-NI nur für sich, ist es schon wahnsinnig schnell:

root@happy:pts/7 ...tools/crypto> ./cryptotest -z 1000000                                      [17:05:48]
   2.474 sec, 2000000    aes crypts,      16 bytes, 12933155 byte/sec,    98.7 Mb/sec
   1.770 sec, 2000000    aes crypts,      32 bytes, 36165589 byte/sec,   275.9 Mb/sec
   1.797 sec, 2000000    aes crypts,      64 bytes, 71219880 byte/sec,   543.4 Mb/sec
   1.935 sec, 2000000    aes crypts,     128 bytes, 132327848 byte/sec,  1009.6 Mb/sec
   2.245 sec, 2000000    aes crypts,     256 bytes, 228084306 byte/sec,  1740.1 Mb/sec
   2.718 sec, 2000000    aes crypts,     512 bytes, 376724323 byte/sec,  2874.2 Mb/sec
   4.511 sec, 2000000    aes crypts,    1024 bytes, 453987442 byte/sec,  3463.6 Mb/sec
   5.798 sec, 2000000    aes crypts,    2048 bytes, 706458420 byte/sec,  5389.9 Mb/sec
   9.793 sec, 2000000    aes crypts,    4096 bytes, 836532621 byte/sec,  6382.2 Mb/sec
  24.972 sec, 2000000    aes crypts,    8192 bytes, 656082557 byte/sec,  5005.5 Mb/sec
   1.769 sec, 2000000 aes192 crypts,      16 bytes, 18088314 byte/sec,   138.0 Mb/sec
   1.749 sec, 2000000 aes192 crypts,      32 bytes, 36597109 byte/sec,   279.2 Mb/sec
   1.823 sec, 2000000 aes192 crypts,      64 bytes, 70218016 byte/sec,   535.7 Mb/sec
   1.982 sec, 2000000 aes192 crypts,     128 bytes, 129185731 byte/sec,   985.6 Mb/sec
   2.305 sec, 2000000 aes192 crypts,     256 bytes, 222166488 byte/sec,  1695.0 Mb/sec
   2.959 sec, 2000000 aes192 crypts,     512 bytes, 346103680 byte/sec,  2640.6 Mb/sec
   5.235 sec, 2000000 aes192 crypts,    1024 bytes, 391203051 byte/sec,  2984.6 Mb/sec
   6.539 sec, 2000000 aes192 crypts,    2048 bytes, 626368748 byte/sec,  4778.8 Mb/sec
  11.333 sec, 2000000 aes192 crypts,    4096 bytes, 722869347 byte/sec,  5515.1 Mb/sec
  28.986 sec, 2000000 aes192 crypts,    8192 bytes, 565229109 byte/sec,  4312.4 Mb/sec
   1.724 sec, 2000000 aes256 crypts,      16 bytes, 18562292 byte/sec,   141.6 Mb/sec
   1.787 sec, 2000000 aes256 crypts,      32 bytes, 35811007 byte/sec,   273.2 Mb/sec
   1.890 sec, 2000000 aes256 crypts,      64 bytes, 67710967 byte/sec,   516.6 Mb/sec
   2.074 sec, 2000000 aes256 crypts,     128 bytes, 123414414 byte/sec,   941.6 Mb/sec
   2.414 sec, 2000000 aes256 crypts,     256 bytes, 212059826 byte/sec,  1617.9 Mb/sec
   3.172 sec, 2000000 aes256 crypts,     512 bytes, 322818406 byte/sec,  2462.9 Mb/sec
   5.623 sec, 2000000 aes256 crypts,    1024 bytes, 364249223 byte/sec,  2779.0 Mb/sec
   7.367 sec, 2000000 aes256 crypts,    2048 bytes, 556009772 byte/sec,  4242.0 Mb/sec
  12.940 sec, 2000000 aes256 crypts,    4096 bytes, 633075000 byte/sec,  4830.0 Mb/sec
  32.442 sec, 2000000 aes256 crypts,    8192 bytes, 505024787 byte/sec,  3853.0 Mb/sec

Das Tool findet sich in /usr/src/tools/tools/crypto. Aber dieser Benchmark sendet halt nur die Instruktionen an die CPU und arbeitet auf einer sehr kleinen Menge Daten, die sogar in die Caches passt. Bei GELI sieht es anders aus. Dort können Daten nicht mehr direkt gelesen und geschrieben werden, sie müssen aus dem RAM durch die CPU, von der CPU in den RAM und von dort auf Platte. Das ist wahnsinnig teuer. Dazu kommen dann die unter FreeBSS im Vergleich zu anderen Systemen "for historical reasons" ebenfalls sündteuren Kontextwechsel zwischen Kernel und Userland, eingeschränkt im Kernel noch zwischen den Kernelthreads, etc. Kurz um, da geht viel verloren.

Ein einfaches "dd if=/dev/zero of=testfile bs=4M" ist zwar ein Milchmädchentest ohne große Aussagekraft, aber bestätigt es dennoch:

last pid: 11363;  load averages:  0.60,  0.26,  0.19                              up 0+08:28:30  17:02:08
147 processes: 3 running, 143 sleeping, 1 waiting
CPU:  0.1% user,  0.0% nice, 13.0% system,  0.3% interrupt, 86.5% idle
Mem: 1256M Active, 12G Inact, 2253M Wired, 164M Cache, 1643M Buf, 318M Free
Swap: 8192M Total, 3616K Used, 8188M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root          8 155 ki31     0K   128K CPU7    7  65.7H 657.13% idle
  113 root          1  52    -     0K    16K CPU5    4   3:40 78.96% g_eli[0] ada1p2
    3 root          1 -16    -     0K    16K crypto  6   0:27  7.28% crypto returns
11363 yamagi        1  24    0 18272K  5224K wswbuf  2   0:03  6.79% dd
   14 root          3  -8    -     0K    48K -       2   0:41  3.96% geom
   12 root         24 -84    -     0K   384K WAIT    0   8:05  0.59% intr
    7 root          1 -16    -     0K    16K psleep  6   0:02  0.10% pagedaemon
 3702 yamagi        8  20    0  1230M   666M uwait   1  52:21  0.00% opera
 3683 yamagi        1  20    0  3215M 42144K select  2   8:47  0.00% Xorg
 4373 yamagi       11  20    0   144M 15200K uwait   5   3:23  0.00% VBoxSVC

Der GELI-Worker konsumiert trotz AES-NI etwa 75 bis 80 Prozent eines meiner 8 Hardwarethreads. Würde die Platte nicht abregeln, würden es noch mehr werden. Wer will, kann es mit einer RAM-Disk nachstellen... Es ist, wie h^2 oben sagte. AES-NI bringt in praktischen Szenarien annähern nichts, solange die CPU schnell genug ist. Das mag je nach System etwas mehr oder weniger ausgeprägt sein, aber unter dem Strich kann man es so schon unterschreiben. Interessant wird AES-NI dann, wenn die CPU wenig Leistung hat. Deshalb ist es auch so bescheuert, dass Intel AES-NI in die dicken Quadcores integriert, aber nicht in die relativ langem Core i3 Dualcores.

Für den Threadersteller bedeutet das: Wenn er groß verschlüsseln will, dürfte der Celeron keine Wunder vollbringen. Spätestens, wenn es über mehrere Platten parallel geht, ist da schnell Schicht im Schacht. Da die CPU kein AES-NI kann, muss er also in jedem Fall eine andere einsetzen. Und da die dicken CPUs im Großen und Ganzen mit AES-NI auch für Softcrypto schnell genug sind, kann er sich auch ein System mit ECC bauen. Das ich dennoch zu AES-NI geraten habe, liegt einfach daran, dass er dann auch mit sehr vielen Platten keine Probleme bekommen wird.

[lockdoc]

Zitat von Yamagi

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  113 root          1  52    -     0K    16K CPU5    4   3:40 78.96% g_eli[0] ada1p2

Heisst das jetzt soviel, dass ich ein Core pro Geli verschluesselte Festplatte brauche?

[jmt]

Es wäre ja auch mal interessant zu erfahren, welchen Durchsatz man mit den verschiedenen CPUs erhält. Auf einem AMD E-350 mit 1,6 GHz komme ich auf ca. 30 MB/s. Geht man davon aus, dass der G530 3 Mal so schnell ist wie mein AMD, dann sollte man mit 90MB/s verschlüsseln können. Das wäre für eine 35€ teure CPU gar nicht so schlecht. Im Vergleich müsste man sich dann einen i3 ansehen, der ja auch 2 Kerne hat. Er ist mit 150€ vier mal so teuer.

[Yamagi]

Naja, je teuerer Hardware wird, umso geringer wird ihr Leistungsanstieg mit steigendem Preis. Sehr extrem wird es bekanntlich im High-End Segment, wo sich für wenige Prozent Mehrleistung der Preis verfielfacht. Wir können ja mal einen kleinen Test von Softwarecryptos machen:

openssl speed aes-128-cbc -multi $N

Wobei $N die Anzahl der zu nutzenden Threads angibt. Dabei sollte man niemals mehr Threads nehmen, als auch Hardwarethreads vorhanden sind, da die Ergebnisse sonst stark verfälschen. OpenSSL kann zwar auch AES-NI, aber zumindest bei der Version im FreeBSD-Basisystem hat es so gut wie keine Auswirkung....

Mein Core i7 2600k mit einem Thread:

aes-128 cbc     162705.96k   194656.24k   195629.22k   196995.02k   197284.19k

Und 8 Threads (4 Kerne, 4 Hyperthreading-Threads):

aes-128 cbc     715380.37k   743652.48k   766106.55k   781248.82k   800238.44k

Die Werte geben den Durchsatz bei verschienen Blockgrößen an. Von Links nach Rechts:
- 16
- 64
- 256
-1024
- 8192

[jmt]

Dann hier mal das Ergebnis für einen AMD E-350 Processor (1600.03-MHz K8-class CPU)

1 Thread:

aes-128 cbc      54899.08k    57330.07k    58675.49k    58964.11k    59009.15k

2 Threads:

aes-128 cbc     108034.26k   114575.00k   117139.52k   117552.51k   117812.82k

[lockdoc]

Intel® Core™2 Duo E8400 (3600.21-MHz K8-class CPU)

1 Threads

aes-128 cbc     161482.81k   185353.42k   187951.05k   188612.64k   187614.93k
aes-256 cbc     128028.73k   146168.03k   146826.45k   148282.93k   147364.84k

2 Threads

aes-128 cbc     346950.25k   368943.20k   374243.49k   376130.45k   374262.94k
aes-256 cbc     269580.07k   288470.20k   294783.01k   292398.47k   293805.38k

[hades]

Zitat von lockdoc

Intel® Core™2 Duo E8400 (3600.21-MHz K8-class CPU)

Die 3600.21-MHz sind ein Tippfehler, oder?
Mein E8400 hat nur 3GHz...

[lockdoc]

Zitat von hades

Die 3600.21-MHz sind ein Tippfehler, oder?
Mein E8400 hat nur 3GHz...

Der ist uebertaktet auf 3600

[mark05]

hi

koennte man die ergebnisse nicht ins wiki packen ?

holger

[lockdoc]

Zitat von mark05

hi

koennte man die ergebnisse nicht ins wiki packen ?

holger

Mal ganz simpel gemacht
http://wiki.bsdforen.de/talk/hardware/cpu_benchmark

[mark05]

man manchmal ist man hier schneller als die polizei erlaubt

[unull]

Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz:

> openssl speed aes-128-cbc -multi 1
aes-128 cbc     109200.24k   169109.72k   195591.42k   203891.71k   206602.24k
> openssl speed aes-128-cbc -multi 8
aes-128 cbc     485056.37k   722403.80k   825276.84k   855811.75k   863835.48k

CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (2800.16-MHz K8-class CPU)

> openssl speed aes-128-cbc -multi 1
aes-128 cbc     134982.00k   150486.73k   153712.06k   154344.97k   154385.21k
> openssl speed aes-128-cbc -multi 8
aes-128 cbc     559333.56k   544004.53k   616396.96k   632687.41k   636112.45k

[Yamagi]

Ich hab mal einen ganzen Batzen ältere Benchmarks von ca. 2007 ins Wiki geworfen.

[lockdoc]

Intel® Core™2 Duo E8400 (3997.16-MHz K8-class CPU)
Da geht noch was xD

> openssl speed aes-128-cbc -multi 1
aes-128 cbc     195875.15k   205990.16k   207445.34k   209390.52k   208383.89k

> openssl speed aes-256-cbc -multi 1
aes-256 cbc     155114.54k   162360.48k   164132.32k   164689.68k   163645.26k

> openssl speed aes-128-cbc -multi 2
aes-128 cbc     389903.43k   410108.32k   414994.60k   417770.78k   415481.32k

> openssl speed aes-256-cbc -multi 2
aes-256 cbc     309379.63k   323852.70k   327428.13k   321747.31k   326231.08k

[q000te]

Ich hab mal eben alles, auf das ich schnell Zugriff hatte getestet:
ein E-350 (2x 1,6 GHz), einen Athlon II X4 600e (4x 2,2 GHz) und einen Phenom II X4 925 (4x 2,8 GHz).
Im Anhang die Werte einmal als Tabellenbild (ja, dass ist doof) und zweimal als Plot (svg / png).

EDIT: Ich hab zum Vergleich mal mein X40 getestet, das bringt mit Akku ca. 1/4 der Leistung vom E-350 und mit Netzteil ca. 1/2.

Neuer Plot: (nur 1 Thread)