AES-NI Nutzung in VPS

  • Hallo,


    ich habe gerade meinen neuen VPS500 G7 in Betrieb genommen. Sieht soweit alles ganz gut aus. Betriebssystem ist Debian Stretch. Ein "cat /proc/cpuinfo" zeigt unter Flags die unterstützten Erweiterungen des Instruktionssatzes an. Leider werden "aes" und "pclmulqdq" nicht unterstützt. Ich denke gerade die beiden wären für viele hier ein großer Vorteil, da sie Verschlüsselung (besonders AES-GCM) und Signierung wirklich stark beschleunigen und zumindest OpenSSL sie in fast jeder Distro von selbst nutzt. Das könnte besonders Last-Bursts auf den Servern lindern. Da hätten ja alle, was davon...

    Ich weiß nicht wie heterogen die Netcup-Server sind auf denen VPS gehostet wird. Für die Leistung wäre es natürlich am besten den kompletten Instruktionssatz des Host weiter zugeben. Dann ändert sich aber eventuell der Instruktionssatz, wenn eine VM auf einen anderen Server umgezogen wird. Das mag manche Kunden stören.

    aes und pclmulqdq (zusammen mit sse3, ssse3, sse4.1, sse4.2) werden seit Intel Westmere/ Nehalem-C (2010) unterstützt. Intel SandyBrdige (2011) und AMD Bulldozer (Opteron 62xx, 2011) unterstützen zusätzlich noch avx und xsave. Ich denke die Netcup-Server werden keine älteren Prozessoren einsetzten und sollten somit in der Lange die Instruktionen anzubieten.

    Kann Netcup den Parameter "qemu -cpu" Parameter anpassen? Je nachdem wie heterogen die Server sind auf einen wirklichen Prozessor (ein älterer Intel sollte von einem neuen abbildbar sein) oder zumindest dem generischen "qemu64" oder "kvm64" ein paar weitere Instruktionen, die er unterstützten soll, mitgeben? Mit x2acpi wird das ja schon gemacht, glaube ich. Instruktionen hinzuzufügen, sollte, meine ich, keinen Bestandskunden stören, oder?


    Ich habe OpenSSL mal gezwungen aes und pclmulqdq zunutzten (egal, was die Cpu Flags anzeigen) und zumindest auf meinem Host geht das. Aber wie ich den ganzen Services, die die OpenSSL-Lib nutzten, das beibringe, weiß ich noch nicht. Falls jemand das schon gemacht hat, bin ich für Infos dankbar.

  • Diesem Wunsch schließe ich mich an.


    Auf meinem VPS, Performance ohne AES-NI Flag, ermittelt mit: openssl speed -elapsed -evp aes-128-gcm

    Code
    1. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    2. aes-128-gcm 38157.24k 43114.26k 45115.65k 51486.72k 52180.31k

    Zum Vergleich, wenn man die Umgebungsvariable export OPENSSL_ia32cap="+0x200000200000000" setzt um die Verwendung von AES-NI zu erzwingen:

    Code
    1. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    2. aes-128-gcm 99506.82k 158212.54k 158870.53k 188262.74k 199183.02k

    das ist eine Steigerung um den Faktor 2-4 je nach Blockgröße.

  • Nimmt man einen Server mit physikalischen Cores (RS 2000 SAS G7SEa1), sieht das ganze schon viel viel besser aus:

    Code
    1. root@root:~# openssl speed -elapsed -evp aes-128-gcm
    2. OpenSSL 1.0.1t  3 May 2016
    3. built on: Thu Nov  2 14:01:13 2017
    4. options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) 
    5. The 'numbers' are in 1000s of bytes per second processed.
    6. type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    7. aes-128-gcm     376293.16k   866140.67k  1306579.54k  1420143.96k  1458309.80k
  • Beim roten Konkurrenten ist das Folgende in der Cloud aktiviert:


    fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti spec_ctrl fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f rdseed adx smap clwb avx512cd xsaveopt xsavec xgetbv1 arat

  • Guten Abend,


    Bei unserer neuen VPS Generation 8 steht aktuell neben den bisherigen Features noch AES, SSSE3, SSE4.1, SSE4.2 und zudem PCID zur Verfügung. Da VPS allerdings nur mit vCores verkauft werden, sind diese Features nur optional verfügbar, wenn sie vom Host unterstützt werden (was aber auf alle aktuellen Intel CPU's zutrifft). Das volle Featureset bleibt weiterhin unseren Rootservern vorbehalten.


    Ich wünsche der Community ein schönes Wochenende :)

  • Danke [netcup] Brian A. für die Rückmeldung.

    Die hier angefragten CPU-Flags aes pclmulqdq sollten ja eigentlich auf allen derzeit bei euch als VPS-Hosts genutzten Maschinen technisch bereitstellbar sein. Sie daher den KVM-Gästen der VPS-Reihe 7 nicht zu offerieren erscheint mir unzweckmäßig. Es ist ja nicht so, dass nur wir Kunden davon profitieren würden, wenn ihr die vCores mit diesen beiden CPU-Flags konfigurieren würdet. Netcup würde ebenfalls davon profitieren, weil anstelle AES-Runden in Software zu rechnen die Hardware-Implementierung verwendet wird, somit sinkt die CPU-Auslastung des Hosts.

  • Kann ich bestätigen, und der Unterschied ist gewaltig:


    Meine Messung openssl speed -elapsed -evp aes-128-gcm von oben vom 02. Februar:

    Code
    1. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    2. aes-128-gcm 38157.24k 43114.26k 45115.65k 51486.72k 52180.31k

    Und nun soeben:

    Code
    1. type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    2. aes-128-gcm     179710.91k   454486.02k   642883.41k   716375.72k   714416.13k
  • Obs an dem liegt, wage ich zu bezweifeln ...

    das am RS 1000 G7

    Code
    1. OpenSSL 1.0.1e-fips 11 Feb 2013
    2. built on: Wed Mar 22 21:43:28 UTC 2017
    3. The 'numbers' are in 1000s of bytes per second processed.
    4. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    5. aes-128-gcm 331801.06k 769686.49k 1097882.79k 1190127.62k 1213068.63k

    das am VPS 100 G7

    Code
    1. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    2. aes-128-gcm 206019.65k 509532.10k 688837.55k 748356.27k 759666.01k
  • hier mal auf meinem Router ausprobiert

    Code
    1. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    2. aes-128-gcm 108756.94k 187816.31k 242228.74k 263792.30k 269530.45k

    die CPU vom Router: ein Intel Celeron N3150,

    ich denke das liegt auch an der Linux Distribution, gunnarh welche verwendest Du?

  • Am oben von mir genannten VPS läuft bewusst noch eine alte Debian 8 Installation (mit aktuellem Security-Patchstand), OpenSSL 1.0.1t.

    Was meinst Du mit "Obs an dem liegt, wage ich zu bezweifeln"? Die von Dir am VPS gemessenen Werte sind doch in der gleichen Größenordnung wie die von mir nachdem AES-NI freigeschaltet wurde. Sehe da ad-hoc nicht ungewöhnliches?

  • bei mir ein gepatchtes CentOS 6, das auch auf meinem Router, und irgendwie kommt es mir schon etwas merkwürdig vor,

    daß - auch wenn ein VPS nur virtuell was von einer fetten Xeon-CPU abbekommt - nur knapp 1/3 ohne dem AES-NI hergibt

    was die ultrabillige 4 Watt CPU - falls die überhaupt AES-NI hat - von meinem Router hergibt ...

    ja die 200 und deine 179 irgendwas sind in der Größenordnung; schade, daß ich keinen Testwert ohne dem AES-NI hab;


    ich hab noch in Erinnerung, als ich mal OpenSSL auf einem Debian von Hand compilieren wollte und fuhr mit dem Intel Compiler auf;

    es lief zwar schneller, lieferte dafür aber nur Hausnummern und bestand auch den Selbsttest nicht :D


    der sagt der bogomips-Wert aus?

    heißt hier mehr automatisch auch schneller?


  • Verstehe nicht, was Du bemängelst.


    Nehmen wir der Einfachheit halber die Werte die mit 8k Blockgröße ermittelt wurden:


    ohne AES-NI mit AES-NI
    mein VPS mit Single-Core vCPU 52 MB/Sek 714 MB/Sek
    Dein Router mit Intel Celeron N3150 269 MB/Sek
    Dein VPS 100 G7 (mit Single-Core vCPU) 759 MB/Sek
    Dein RS 1000 G7 (der 2 exclusive Kerne bietet) 1213 MB/Sek


    Für mich sind das äußerst nachvollziehbare Werte - Deine Aussage "nur 1/3 von ... hergibt" verstehe ich nicht. Worauf beziehst Du Dich konkret?

  • mir kommt das Ergebnis vor der AES-NI-Aufschaltung von Deinem VPS eher mikrig vor, schließlich bekommt

    der VPS was von einer fetten CPU ab, hingegen mein Router ist nur 'ne billige 4 Watt CPU;

    mittels export OPENSSL_ia32cap="~0x200000200000000" deaktiviert man die AES-NI Nutzung und da kommt

    bei meinem Router (billiger Celeron) das

    Code
    1. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    2. aes-128-gcm 26200.02k 30923.46k 71971.16k 77879.98k 79301.29k

    beim RS 1000 G7 (fetter Xeon - 2 Cores) das

    Code
    1. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    2. aes-128-gcm 63546.82k 72344.75k 156819.18k 166465.88k 171057.15k

    beim VPS 100 G7 (1 vCPU)

    Code
    1. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    2. aes-128-gcm 45834.99k 53907.01k 131430.83k 144672.43k 146634.07k

    mit dem "1/3" bezog ich mich auf die Werte der 1ten Spalte; werden hier mehrere Cores genutzt wenn vorhanden

    oder ist es ausschließlich Single-Thread-Performance die hier gefragt sind?

  • Die Änderung seitens NetCup war nicht nur AES, sondern z.B. auch pclmulqdq.


    Mein VPS hatte vor Aktivierung der neuen CPU-Features ca. 52MB/Sec geschafft, macht heute ca. 700MB/Sec und hat - wenn man wie von Dir beschrieben mittels export OPENSSL_ia32cap="~0x200000200000000"die AES-Hardwarenutzung deaktiviert - aktuell ca. 121MB/Sec chiffriert. Somit ist AES nicht die einzige Performance-Beschleunigung die nun wirksam ist, sondern eben z.B. auch pclmulqdq


    Der Aufruf von openssl speed -elapsed -evp aes-128-gcm lastet bei mir nur einen Core aus. Um z.B. zwei Cores gleichzeitig auszulasten kann man openssl speed -elapsed -evp aes-128-gcm -multi 2 starten.

  • Ok, jetzt sieht die Welt etwas anders aus,

    weil mein Router (mit allen 4 Cores) knapp mehr hat,

    als 1 Core vom RS aber doch das doppelte vom VPS (Single-Core)