That patch applies to openssl as shipped in Hardy, but doesn't appear to have any effect. After patching openssl, rebuilding the packages and installing them, `openssl engine padlock' reports:
(padlock) VIA PadLock (no-RNG, ACE)
on my C3 thin clients. That should get me at least accelerated aes-128, but yet:
openssl speed aes-128-cbc -engine padlock
loads the padlock engine successfully but does NOT appear to be using its crypto facilities. Performance remains miserable, around 10MB/s of aes-128-cbc throughput. SSH gets ~5 MB/s throughput, which seems reasonable given the other overheads it faces.
If I build openssl-0.9.8h upstream and test with that I also see no performance change.
The processor DOES report ACE support. CPUinfo:
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en
There's no change when the padlock-aes module is loaded (but it shouldn't be needed for openssl/openssh anyway, as padlock is done in userspace with CPU instruction extensions).
It's like OpenSSL is silently falling back to software crypto at some level. I haven't dug into it deeply yet, but I thought it important to mention that the proposed fix does NOT appear to work on my hardware.
This support is *REALLY* important for use of C3/C7 machines as LTSP thin clients, because currently the X server and network (via ssh) fight for CPU, severely limiting performance. Using the hardware crypto should massively reduce SSH's CPU demands and dramatically boost performance.
Full CPUInfo:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping : 8
cpu MHz : 666.577
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en
bogomips : 1334.91
clflush size : 32
That patch applies to openssl as shipped in Hardy, but doesn't appear to have any effect. After patching openssl, rebuilding the packages and installing them, `openssl engine padlock' reports:
(padlock) VIA PadLock (no-RNG, ACE)
on my C3 thin clients. That should get me at least accelerated aes-128, but yet:
openssl speed aes-128-cbc -engine padlock
loads the padlock engine successfully but does NOT appear to be using its crypto facilities. Performance remains miserable, around 10MB/s of aes-128-cbc throughput. SSH gets ~5 MB/s throughput, which seems reasonable given the other overheads it faces.
If I build openssl-0.9.8h upstream and test with that I also see no performance change.
The processor DOES report ACE support. CPUinfo:
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en
There's no change when the padlock-aes module is loaded (but it shouldn't be needed for openssl/openssh anyway, as padlock is done in userspace with CPU instruction extensions).
It's like OpenSSL is silently falling back to software crypto at some level. I haven't dug into it deeply yet, but I thought it important to mention that the proposed fix does NOT appear to work on my hardware.
This support is *REALLY* important for use of C3/C7 machines as LTSP thin clients, because currently the X server and network (via ssh) fight for CPU, severely limiting performance. Using the hardware crypto should massively reduce SSH's CPU demands and dramatically boost performance.
Full CPUInfo:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping : 8
cpu MHz : 666.577
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en
bogomips : 1334.91
clflush size : 32