Śmiesznie kiepska wydajność z OpenSSL AES/GCM na Raspberry PI 2

Question

Opracowałem prosty program w C++ do testowania wydajności wywołań AES/GCM OpenSSL do interfejsu EVP. To, co robi, to pobranie łańcucha o długości 1024 bajtów, zaszyfrowanie go za pomocą klucza, a następnie zaszyfrowanie wyniku za pomocą tego samego klucza i znowu i znowu. Używam inkrementalnych 4-bajtowych wektorów inicjalizacyjnych.

Kiedy testowałem to na moim MacBooku Pro (Intel i7), wynik był imponujący: wykonanie jednej operacji 104676 iteracji powyższej procedury zajęło dokładnie sekundę. To szybkość szyfrowania 1 GB/s. 8 GB/s (więcej lub mniej), jeśli wykorzystamy wszystkie rdzenie jednocześnie.

Teraz przeportowałem ten sam test porównawczy na Raspberry PI 2. Kiedy go uruchomiłem, wykonanie 1024 iteracji zajęło 0,16 sekundy. To mniej więcej 6 MB/s, na jednym rdzeniu.

Teraz rozumiem, że istnieje ogromna różnica między nowoczesnym, kosztownym procesorem i7 a małym procesorem ARM, który działa na Raspberry, ale wciąż jest 170 razy szybszy. Tak więc przed założeniem, że Raspberry PI 2 jest naprawdę, że źle, chciałem sprawdzić, czy te parametry są uzasadnione.

Czy ktoś zrobił coś w tym rodzaju? Czy szybkość kodowania 6 MB/s jest rozsądna w przypadku Raspberry? Czy robię coś złego?

(Zasilam go przez mój Macbook USB: czy to może być takie powolne, ponieważ nie otrzymuje wystarczającej mocy?) To z pewnością nie brzmi rozsądnie, w ogóle by się nie włączało, prawda? mechanizm downclockingu, aby zaoszczędzić energię?)

UPDATE 1: Zrobiłem openssl -evp speed aes-256-cbc zarówno na moim MacBooka, jak i Raspberry.

Na Macbook:

type    16 bytes  64 bytes 256 bytes 1024 bytes 8192 bytes 
aes-256-cbc  534591.95k 564057.62k 566522.81k 570717.87k 574876.33k 

Na Malina:

type    16 bytes  64 bytes 256 bytes 1024 bytes 8192 bytes 
aes-256-cbc  14288.53k 16653.74k 17165.31k 17298.43k 17337.00k 

To jeszcze czynnik 33, ale procesor Intel może wykorzystać sprzętowej akceleracji AES nazywa. Mimo to, o ile wiem, tryb GCM powinien być znacznie szybszy niż CBC. Nie wiem dlaczego, ale wygląda na to, że nie jest wyznacznikiem prawo openssl do GCM, ale nawet zakładając, że wykonują identycznie Brakuje mi czynnik 3.

UPDATE 2 sprawdzone strony: http://elinux.org/RPi_Performance#OpenSSL. Wygląda na to, że brakuje mi 10 MB/s więcej. Suma całkowita: 27 MB/s przy AES/CBC (tak jak powinno być) vs 6 MB/s przy AES/GCM (tak jak jest).

Answer 1

Jeśli jeszcze go nie uwzględniono, dlaczego współczynnik 3 nie zostałby wyjaśniony przez współczynnik około 3 różnicy mocy obliczeniowej?

Raspberry Pi 2 ma procesor 900Mhz, a typowy procesor i7 ma 2,8 GHz, co powoduje, że Pi ma mniej więcej jedną trzecią mocy obliczeniowej.

Ponadto, nie wiem, skąd bierze się wniosek, że GCM powinna być szybsza niż CBC w tych okolicznościach. CBC nie zapewnia uwierzytelniania, więc samo to powinno sprawić, że GCM będzie wymiernie wolniejsze (chociaż może nie będzie to czynnik 4, który widzisz).

Oczywiście, że wychodzi poza okno, gdy wprowadza się wiele rdzeni, biorąc pod uwagę, że CBC nie może być zsynchronizowany i GCM może.

Answer 2

Procesor Intel ma dedykowaną obsługę sprzętu przy użyciu rozszerzenia AESNI. Jeśli skompilujesz bez tego, otrzymasz około 250 MB/s. Ta różnica w wydajności wydaje się rozsądna. (I ile GHz dowolny procesor nie mówi nic o wydajności, chyba że jest to dokładnie ten sam typ procesora z innym zegarem)