Back to topic. Those KeSaveFloatingPointState calls, are those in a different thread in the VeraCrypt process? These calls are inside each encryption thread from the device driver, called at DecipherBlocks() routine. I've done a test by just disabling those calls and the CPU usage has been reduced to under 15% in the Core i5. Not the best solution, but I was expecting to break something, which it didn't. DC does have a similar procedure, but with this KeGetCurrentIrql() check. long save_fpu_state(unsigned...
I'm not sure what you mean by benchmarking with no encryption - I assume you mean looking at the CPU when doing raw disk transfers without encryption. Yes, that's it. A good indication of what CPU usage you'll see in VeraCrypt is to use the VeraCrypt benchmark. Set it to a buffer size of 500MB and let it run. Whatever maximum throuput it tells you for AES can be used to determine what VeraCrypt's average CPU usage will be during sustained read/write: CPUUsage% = (DriveSpeed ÷ EncryptionSpeed) × 100...
I'm not sure what you mean by benchmarking with no encryption - I assume you mean looking at the CPU when doing raw disk transfers without encryption. Yes, that's it. A good indication of what CPU usage you'll see in VeraCrypt is to use the VeraCrypt benchmark. Set it to a buffer size of 500MB and let it run. Whatever maximum throuput it tells you for AES can be used to determine what VeraCrypt's average CPU usage will be during sustained read/write: CPUUsage% = (DriveSpeed ÷ EncryptionSpeed) × 100...
Hi. I've noticed that while reading or writing in a encrypted volume (AES-SHA256) the CPU usage usually spikes up to 40%, which is a major issue to my usage. Tested on both 1.17 and 1.21 VeraCrypt versions in Windows XP and Windows 7. I have also benchmarked these operations with no encryption at all and an encrypted volume with DiskCryptor (which is a TC derivative), and the CPU usage never went over 3%. It had been tested in a virtual machine, a machine with a 45nm Core 2 Duo and 2gb of RAM and...