New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Nope, still returns
OPENSSL_ia32cap=0x80202001478bfffd:0x0000000000000000:0x0000000000000000:0x0000000000000000:0x0000000000000000Okay that means it's working fine, you just have an old CPU so only LV0 is set. Notice how now it's
0x80202001478bfffdbut before it was0x82202001478bfffd. That means, after that reboot, it's successfully enabled AES-NI.Restart the shell or
source /etc/environmentto get the modified value back and tryopenssl speed -evp aes-256-ctragain and you should see substantial improvements compared to before the reboot.It was more or less the same, cannot really say there is a substantial improvement but if it worked. I wonder if upgrading the kernel will help (I am on 6.12 currently) and doing setcpuid=153.
I think in your case openssl is not seeing the
OPENSSL_ia32capenvironment variable at all.It'll let you know whenever it's overriding the cpuid flags, a snippet from my own tests:
(See the
env:0x82382203478bfffdat the end.)Also in my Gcore VM it's significantly faster:
No, it is. It showed a different output after he unset the variable.
The output with the variable intact:
The output after he unset it (note the 0x822... became 0x802...):
So it definitely sees it, but if nothing is actually happening performance-wise, there must be another reason.
Ya something is not working on my VM.
Ahhh, me weeb-brain misread that.
Can you try
OPENSSL_ia32cap=0x82382203478bfffd openssl speed -elapsed -evp aes-256-ctrLooks like my value works for you?
68163.34kvs3239646.55kAh, seems like it did the trick, even though I still get zeros everywhere in the output of
openssl info -cpusettingsThat's normal for your CPU, given that you got that even after you did that
unsetcommand.I thought it was weird at first, but apparently the CPU is just old.
Yep, welcome to Armenia but well...it is what it is, hopefully it will give my tor relay a boost.
If you don't have much RAM, another thing that'll give it a nice boost is this:
That'll reduce RAM usage by ~70%, which can improve performance significantly on low-memory systems. It replaces the default Glibc memory allocator, ptmalloc3, with one called jemalloc2 which is much better at resisting memory fragmentation.
Simply incorrect not sure where you people are educated.
Yes ChaCha20 has seen wide mass adoption especially in VPN space, but AES and other original forms of encryption have had plenty of there own developments are are still heavy more implemented overall.
AES-GCM, AES-GCM-SIV are actively modern competitors that still take use of hardware acceleration.
Let’s not forget AES-XTS for other applications outside of general web traffic, data encryption king.
1Gb, fix applied, many thanks.
Also if anyone else is gooning in AES-GCM like me, enabling PCLMULQDQ alongside AES-NI will speed up AES-GCM even further.
Just had to use
's/(0x[0-9a-f]{16})/sprintf("0x%016x", hex($1) | (1 << 57) | (1 << 33))/e'as the perl argument.Are there even any CPUs wit VT that do not have AES? Atom maybe?
This is for when the host CPU does support AES-NI but the flag is not set on the VM's CPU.
For instance Gcore's basic VMs don't have AES-NI flag set but the host CPU does in fact support it.