VeraCrypt / Forums / General Discussion: SSD Very Slow Performance Compared to BitLocker (using AES)

John Joseph - 2018-01-30

Hello,

I'm trying to solve a performance issue I'm having in Windows 10.
I'm using an SSD.

VeraCrypt gives me AES benchmarks on the order of more than 4 GB/sec by the way.

Here are my performance results of CrystalDiskMark under 3 scenarios: non encrypted, partition encrypted with VeraCrypt + AES, BitLocker Encrypted:

Non encrypted (Q = queue depth, T = threads), figures are READ WRITE:

Seq Q32T1 : 562 MB/s 763 MB/s
4KiB Q8T8 : 191 MB/s 200 MB/s
4KiB Q32T1: 179 MB/s 167 MB/s
4KiB Q1T1: 19 MB/s 35 MB/s

Encrypted (VeraCrypt, AES) :

Seq Q32T1 : 391 MB/s 363 MB/s
4KiB Q8T8 : 18 MB/s 30 MB/s
4KiB Q32T1: 17 MB/s 30 MB/s
4KiB Q1T1: 8 MB/s 16 MB/s

Encrypted (BitLocker) :

Seq Q32T1 : 342 MB/s 729 MB/s
4KiB Q8T8 : 192 MB/s 197 MB/s
4KiB Q32T1: 190 MB/s 204 MB/s
4KiB Q1T1: 13 MB/s 25 MB/s

As you can see, both BitLocker and VeraCrypt impact performance, but the small blocks tests on VeraCrypt are completely crippled, about 10 times slower than BitLocker !
Any ideas (I tried completely disabling Windows Defender, and have no other anti-virus, my system is freshly installed, CPU is i7 2820HQ @ 2.9 Ghz)

Thanks,
John.

Last edit: John Joseph 2018-01-30

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2018-01-31

the problem is known. See comaprison with DiskCryptor. It is possible to improve (~1-2 months of work).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

John Joseph - 2018-01-31

Thanks for the answer Alex.

Out of curiosity, do you know what DiskCryptor is doing differently ? It seems VeraCrypt inherited these problems from TC, but I'm wondering what (technically) DiskCryptor is doing more ? More precisely, I would have guessed IO pipelining and parallelization would be part of the answer, but VeraCrypt obviously does that. Some form of more involved IO coalescing that DiskCryptor does or something related to TRIM passthrough maybe? That wouldn't explain the big hits in read tests though and also the Q1T1 results.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Alex - 2018-02-01
  
  Main difference DC and VC (and probably BitLocker) - VC can create file container. DC encrypts volumes only => VC create new IRP for i/O. DC handles original IRP in place.
  
  General data path: VC container in file -> read -> VC get IRP -> VC creates new IRP to file -> thread switch context -> read --> return original IRP
  
  It is possible to create "fastpath". (e.g. for small IRP avoid thread context switch)
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - John Joseph - 2018-02-03
    
    In place IRP processing vs having to generate a new one makes sense to explain these discrepancies, thanks.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

svenk - 2018-11-10

Hi,

I am kind of sorry for reviving this old thread with my first post in this forum, but this topic is why I registered...

Since the issue apparently has been identified ("It is possible to improve (~1-2 months of work)"), may I ask if there are any plans to actually improve the performance? If so, can we expect a solution in on of the upcoming releases?

Would be so nice since this program rocks!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- wat - 2018-12-02
  
  I highly doubt this is going to get fixed anytime soon if at all. It seems to be known for years now.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Alex - 2018-12-02
    
    I wrote about the problem because I know how to solve but for me personally it is not vital. I share my ideas and codes to community if someone can continue - welcome to do.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - svenk - 2018-12-05
      
      Sharing would be great! I am not a developer for this project and cannot help much, but maybe someone can and will. Better performance is always welcome!
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Fghc - 2019-10-08

Maybe this has been fixed with the 1.24 update? VeraCrypt is hard to use with this bug... I just decrypted everything and was ready to move to another program (not sure what yet), because I just got so fed up with it over the course of a few months...

Or any idea when and if this will be fixed at all?

Last edit: Fghc 2019-10-08

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mounir IDRASSI - 2019-10-08

This issue is still open. As Alex explained, it requires changes on the driver handling of IRP which is not trivial and unfortunately, file container support make things complicate for any change of this part.

Currently I'm think of creating a different version of VeraCrypt driver that is dedicated to disks and so we can have more freedom about the implementation of the driver. And the user can switch between a "file contaner+ disk" driver and "disk only" driver using an option in the UI.

I can not give yet a planning for this development but it is on the top list for 1.25.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Katarina Schubitz - 2019-10-20
  
  Isn't it possible to have both drivers at the same time and depending on what you are doing, use either one? So for file containers the slow driver will be used and for drives/partitions the fast driver will be used?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

karnin - 2019-10-31

+1
Performance impact is the main reason for me to keep attached to Bitlocker for system encryption.

Last edit: karnin 2019-10-31

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave - 2021-02-09

More assembly code to improve performance, to replace C and C++?

Last edit: Dave 2021-02-09

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

vonDatuh - 2021-02-24

is there a update on this serious issue?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mati - 2023-02-26

https://github.com/veracrypt/VeraCrypt/issues/136#issuecomment-1009829420

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

SSD Very Slow Performance Compared to BitLocker (using AES)

Open source disk encryption with strong security for the Paranoid

Forums

Help

SSD Very Slow Performance Compared to BitLocker (using AES)

SSD Very Slow Performance Compared to BitLocker (using AES)

Open source disk encryption with strong security for the Paranoid

Forums

Help

SSD Very Slow Performance Compared to BitLocker (using AES) document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

SSD Very Slow Performance Compared to BitLocker (using AES)