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:
Nimmt man das AES-NI nur für sich, ist es schon wahnsinnig schnell:
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:
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.
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:
Code:
GEOM_ELI: Device ada1p2.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI: Crypto: hardwareNimmt man das AES-NI nur für sich, ist es schon wahnsinnig schnell:
Code:
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/secDas 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:
Code:
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% VBoxSVCDer 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.
