This project has moved. For the latest updates, please go here.

SSD speed after encryption & wear leveling

Topics: Technical Issues
Jul 9, 2016 at 11:54 AM
Edited Jul 9, 2016 at 12:57 PM
I know there is no solution to fix the speed to normal after having encrypted SSD with VC.
My question is, what mechanism affects it? Why is the speed going drastically down?

In my case BEFORE read write AFTER read write:

Seq - 1652 MB/s 1200 MB/s -> 1558 MB/s 1195 MB/s
Seq Q32 T1 - 2195 MB/s 1288 MB/s -> 1407 MB/s 1269 MB/s
4K - 46 MB/s 169 MB/s -> 26 MB/s 127 MB/s
4K-64 - 1093 MB/s 340 MB/s -> 53 MB/s 256 MB/s
read times: 0,021 ms 0,016 ms -> 0,142 ms 0,048 ms
score: 2588 -> 854

So drastic change is for read times and mainly 4K-64 - i don't know if using PC daily Windows 7 operates on SSD in 4K-64 fashion - hope not... as the total score goes down drastically... :(

Another thing. As I did not find any proper explanation on the net.
What about wear-leveling after encyrption?
Here is something: http://superuser.com/questions/778619/how-does-ssd-wear-leveling-work-on-software-encrypted-drives
But it's too general.
They just say it doesn't matter as wear-leveling is hardware layer, VC is software.
But they don't exactly explain it. Should I believe in what he says that "Wear-leveling does work on full drives. It moves the data around so that the same blocks aren't being written to over and over, even if the drive is "full", it still does this." and "Wear leveling can work when the drive is full. SSD drives have spare sectors just like HDDs. The firmware can use these sectors (or other internal memory) to copy and swap full, already-programmed sectors. It will be slower than writing to unprogrammed sectors, of course."

Is the last sentence in fact the answer to my very first question in this post? Is it the source of the problem affecting the speed after encryption? Would the solution be to make VC not write random sectors throughout the whole system partition to make the disk appear "full"? Would it then not affect the speed after encryption?
Jul 15, 2016 at 8:43 AM
Edited Jul 15, 2016 at 8:45 AM
I think you answered yourself. Once you encrypt drive, you overwrite it with random data, so the disk controller sees is as full drive and so it cannot properly relocate cells and write to more cells in parallel, which boosts speed on empty drives. Most ssd drives has spare sectors they can use even if the drive is full, but the amount is quite limited, so on a fully encrypted drive the wear level will be bigger and write will be slower.

You can try to clean the ssd with diskpart, which should properly tell the controller to invalidate all the sectors, or use a tool provided by the drive manufacturer. Then create partition only 75% of the drive size, encrypt it, compare the speed and share with us. If you clean the drive properly, write speed should boost and be about the same as on non encrypted drive.

If your concern is performance over security, you can 1. try the built-in aes encryption, some ssd drives has it (samsung). 2. try Bitlocker, which was reported faster on ssd. My guess is it only encrypts the actual data, not all the sectors, but since both option are proprietary, noone really knows how safe that is, or what it actually does with your data.
Jul 29, 2016 at 11:40 AM
Edited Jul 29, 2016 at 1:01 PM
Thanks for your answer. It sounds logical but now I'm not sure again if that's the case. Veracrypt documentation says

"VeraCrypt does not block the trim operation on partitions that are within the key scope of system encryption (unless a hidden operating system is running) and under Linux on all volumes that use the Linux native kernel cryptographic services. In those cases, the adversary will be able to tell which sectors contain free space (and may be able to use this information for further analysis and attacks) and plausible deniability may be negatively affected."

I also checked the command: fsutil behavior query disabledeletenotify
It shows 0 as it should - so TRIM is theoretically enabled. The question if the system directly talks with the controller still remains, though.
And I don't see a way to test it.
I am not so much concerned about speed here but at least I would like wear-leveling to work and protect my drive.
Maybe one day I will perform a test with empty partition nearby but I am not sure if installing fresh OS and encrypting with Vera again giving the same password, then copying backuped files from entirely-configured OS to replace the fresh installation and have the OS ready, wouldn't compromise it.
However, if TRIM was working now, there wouldn't be much difference in speed after creating an empty partition.
If the speed increases, it means TRIM isn't working now. But then I hope at least wear-leveling is working correcly now - simply slower as you suggested. Maybe the disk seen as 100% used doesn't prevent it from wear-leveling to work fine; it should be this way at least. For the moment, I may suppose it's just juggling between the sectors slower, as it needs to move already-written blocks to the buffer and back to the drive, swap them with new data coming, etc... But this all are just speculations... I still miss good technical information or guide how to test those.

Without any good known, I may conclude now that most probably, TRIM isn't working at the moment in my drive. If it was, what would be the bottleneck...? I guess it is as you have written - my disk thinks it's full and wear-leveling is working all the time but through the buffer - which makes it work slower.
Aug 27, 2016 at 5:02 PM
Try DiskCryptor then, you will be amazed at the speed. https://diskcryptor.net

On older PC's only it works fine, as VeraCrypt is too slow, and there is no hardware boost.
Jan 25 at 5:45 PM
i know this is somewhat an old post, but i can not figure out why i am getting an incredible degrading of speed on an all SSD array.
as you can see below, that no encryption and diskcryptor are fairly close, and veracrypt ad truecrypt are fairly close in performance, but there is a huge difference between diskcryptor and veracrypt. i have read the threads as to why this might be, but that is a huge difference, almost like truecrypt and veracrypt are not using all the processors builtin AES engines. i understand that my "write" results are not true results as i have write caching on due to this being a raid-5 array. but none the less the setup is the same for each test.

so here are my questions:
1) is it possible that veracrypt and truecrypt are not parallelizing across all the CPUs builtin AES engines?
i have also read someone indicating that diskcryptor has assembly code that greatly enhances the process, the source code is there to compare with.
2) is that true? and if so, what is stopping this code from being used in veracrypt?
3) am i testing this wrong? not performing tests correctly?
4) are there tweeks i can do to bring veracrypt/truecrypt results up close to diskcryptor?

thank you for your time.

bofc

my setup is:
Dell T5500 workstation
Windows 7 64-bit build 7601 [Service Pack 1] all other updates installed
dual - 6 core (Intel(R) Xeon(R) CPU X5650 @ 2.67GHz) with Hyper-threading turned on
12288 MB of RAM

SSD Array controller:
Adaptec ASR78165 with 1GB cache
read cache is disabled
write cache is enabled

Raid-5 set and initialized and fully formatted/encrypted (100% of disk space) with the application being tested.

SSD Drives: (QTY: 8)
Hitachi HUSMM1680ASS204
800GB SSD enterprise class
interface SAS 12Gb/s

SSD Performance capability:
Read throughput (max MB/s, sequential 64K) 1100
Write throughput (max MB/s, sequential 64K) 765
Read IOPS (max IOPS, random 4K) 130,000
Write IOPS (max IOPS, random 4k) 100,000

using CrystalDiskMark 5.2.1 x64 (C) 2007-2017 for testing

here are the results:

no encryption:
Sequential Read (Q= 32,T= 4) : 3247.226 MB/s
Sequential Write (Q= 32,T= 4) : 3351.777 MB/s
Random Read 4KiB (Q= 32,T= 4) : 399.485 MB/s [ 97530.5 IOPS]
Random Write 4KiB (Q= 32,T= 4) : 59.501 MB/s [ 14526.6 IOPS]
Sequential Read (T= 1) : 1054.652 MB/s
Sequential Write (T= 1) : 1881.124 MB/s
Random Read 4KiB (Q= 1,T= 1) : 18.466 MB/s [ 4508.3 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 36.061 MB/s [ 8804.0 IOPS]
Test : 2048 MiB [S: 0.0% (0.2/5214.9 GiB)] (x5) [Interval=5 sec]
Date : 2017/01/24 10:47:02
OS : Windows 7 Enterprise SP1 [6.1 Build 7601] (x64)


Using DiskCryptor 1.1.846.118
Sequential Read (Q= 32,T= 4) : 3166.594 MB/s
Sequential Write (Q= 32,T= 4) : 3321.441 MB/s
Random Read 4KiB (Q= 32,T= 4) : 422.896 MB/s [103246.1 IOPS]
Random Write 4KiB (Q= 32,T= 4) : 58.644 MB/s [ 14317.4 IOPS]
Sequential Read (T= 1) : 640.948 MB/s
Sequential Write (T= 1) : 1462.769 MB/s
Random Read 4KiB (Q= 1,T= 1) : 10.840 MB/s [ 2646.5 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 43.978 MB/s [ 10736.8 IOPS]
Test : 2048 MiB [S: 0.0% (0.2/5214.9 GiB)] (x5) [Interval=5 sec]
Date : 2017/01/24 20:53:44
OS : Windows 7 Enterprise SP1 [6.1 Build 7601] (x64


Using VeraCrypt 1.19 (64-bit)
Sequential Read (Q= 32,T= 4) : 189.202 MB/s
Sequential Write (Q= 32,T= 4) : 1311.055 MB/s
Random Read 4KiB (Q= 32,T= 4) : 22.525 MB/s [ 5499.3 IOPS]
Random Write 4KiB (Q= 32,T= 4) : 43.161 MB/s [ 10537.4 IOPS]
Sequential Read (T= 1) : 413.959 MB/s
Sequential Write (T= 1) : 516.979 MB/s
Random Read 4KiB (Q= 1,T= 1) : 10.820 MB/s [ 2641.6 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 18.739 MB/s [ 4575.0 IOPS]
Test : 2048 MiB [T: 0.0% (0.2/5214.9 GiB)] (x5) [Interval=5 sec]
Date : 2017/01/25 18:07:41
OS : Windows 7 Enterprise SP1 [6.1 Build 7601] (x64)


Using TrueCrypt 7.1a
Sequential Read (Q= 32,T= 4) : 190.069 MB/s
Sequential Write (Q= 32,T= 4) : 1287.290 MB/s
Random Read 4KiB (Q= 32,T= 4) : 25.516 MB/s [ 6229.5 IOPS]
Random Write 4KiB (Q= 32,T= 4) : 43.138 MB/s [ 10531.7 IOPS]
Sequential Read (T= 1) : 404.121 MB/s
Sequential Write (T= 1) : 532.257 MB/s
Random Read 4KiB (Q= 1,T= 1) : 12.290 MB/s [ 3000.5 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 15.445 MB/s [ 3770.8 IOPS]
Test : 2048 MiB [T: 0.0% (0.2/5214.9 GiB)] (x5) [Interval=5 sec]
Date : 2017/01/25 10:51:16
OS : Windows 7 Enterprise SP1 [6.1 Build 7601] (x64)