Slow transfer from VeraCrypt containers over Wi-Fi

Hello, here is something that has been bothering me for a while. Any help will be appreciated.

Summary: Transfer to and from VeraCrypt containers over Wi-Fi is much slower than Wi-Fi itself. The difference in transfer speed between transfer from VeraCrypt containers over Ethernet and and Ethernet itself is far less pronounced. Why and how to fix it?

Full story:
I have a NAS that holds 4 files - two VeraCrypt containers per HDD. VeraCrypt containers are on a samba share and as a result are mounted and visible on the computer as local drives.

The problem that has been going on for years and I've never had the time to diagnose it properly is that transfer speeds of files being copied to and from these mounted containers are way slower than Wi-Fi.

One could assume that containers themselves are a limiting factor but if the same notebook is connected via Ethernet cable and the same containers are mounted speeds are much better (compared to pure Ethenet transfers to and from a samba share).

For comparison I used the same file copied over the same samba share - just not into a container but onto a share.

Here's how the performance looks (movie files downloaded from NAS from the same samba share to the same computer).

Over Wi-Fi: 66,4 MB/s
Over Wi-Fi from VeraCrypt container: 34,5 MB/s

Over Ethernet: 103,5 MB/s
Over Ethernet from VeraCrypt container: 85,2 MB/s

The difference between pure Ethernet and VeraCrypt Ethernet is roughly 18,3 MB/s or 18%.
The difference between pure Wi-Fi and VeraCrypt Wi-Fi is roughly 32 MB/s or almost 50%.

If that was an issue of some metadata or something similar, the performance hit would be similar for Wi-Fi and Ethernet - either similar % slower or constantly slower by some MB/s. Neither is the case.

Considered and ruled out options:

1. Router issues - tested with TP-Link Archer C7 and Linksys WRT3200ACM (with 4 different firmwares). No difference.
2. NAS issues - tested with two different NASes over the years.
3. OS or computer issues - tested with Windows 10 and Windows 7 on two different laptops with total of 3 different Wi-Fi cards.
4. AV/firewall - tested with multiple AVs and without them.

What explanations I don't buy:

Containers are just slow or Wi-Fi is too slow

If that was the case than why can I download from a container at 85MB/s when I'm connected over Ethernet cable and barely at 34,5MB/s when I'm connected over Wi-Fi. Wi-Fi itself is capable of doing 66,4MB/s and container is capable of 85,2 MB/s so why do I end up with 34MB/s?

Encryption is the issue

NAS is not doing the encryption - it's the notebook that mounts the container. NAS is barely sending data - it doesn't matter if it's encrypted or not.

SAMBA is the issue

If that was the case than the same problem would be visible when notebook is connected over Ethernet cable.
Same NAS and same OS, same samba share as well.

Possible angle:

Ethernet uses Jumbo Frames (typically 9000 bytes) but Wi-Fi 802.11ac frames can be up to 11000 bytes (and some change in size) so this shouldn't be the problem but there is much more metadata with Wi-Fi compared to Ethernet frame which might play some role.

Another possible issue is misalignment of block size and frame size. While my containers use 128bits block size (which was a mistake made back in the day - I'm not willing to create terabytes of containers again to change block size to 4KB) that should affect both Ethernet and Wi-Fi in the same way unless for every frame that barely holds any data there has to be sent a lot of metadata.

I sort fo disproved the latter theory by creating a smaller (several hundred GBs) container with 4KB block size - there was very little difference in terms of performance.


If anyone has sensible ideas - I'm listening.

I cannot do too much testing on the VeraCrypt container because I have a running server with terabytes of data that I can't move anywhere, so while I can change any networking settings I won't be able to provide meaningful testing data by changing containers - containers would have to be deleted and re-created with new settings. That would be terabytes of data copied over and over again.
I can however create smaller test containers.

 

Have you looked at your overall network throughput and CPU utilization during Wi-Fi transfers?

 

Yes I did. Network throughput almost exactly fits data transfer speed, so it's not a case of huge amounts of metadata being transferred.
CPU utilization is low - AES is hardware accelerated and CPU is relatively powerful (i7 7700HQ).

 

Did you ever figure this one out? It's a head-scratcher.

 

I did not, not so far.

 

I bought an external 4TB drive as I have run out of disk bays in my NAS and added that as another volume connected via USB3.
I created a 3TB VeraCrypt container (that took a while) with 4K cluster and copied some data there.

Brand new container that is mostly empty and 4K clusters and still the same issue with Wi-Fi transfer. So it's not the cluster size and not the drive and not the fact that containers have been heavily used or are near full capacity.

I am no closer to figuring that out than I have been...

 

Maybe it's latency.

 

If I ping my NAS I end up with 2ms (that's on Wi-Fi). That is only the device - response time of a HDD would add to that but not by much if the HDD is spinning.

 

On ethernet I bet your ping is under 1ms, probably closer to 0.25.

 

Does windows even show values below 1ms?

EDIT: Windows ping shows 1ms on Ethernet.

 

Oh. Right. Maybe try this:
http://www.cfos.de/en/ping/ping.htm

 

In the end I didn't test the latency over Ethernet more precisely because of the fantastically uncomfortable position I had to sit to be able to do it being at the and of a 3 foot long Ethernet cable.

Instead I came up with a reason why that can't be a factor - latency over Wi-Fi (however slower it is compared to Ethernet) is the same for when I copy data over Wi-Fi from within a VeraCrypt container and when I copy data directly from the share.
So it shouldn't have any effect comparatively but it does.

 

But it could - you are doing the encryption locally (on remote chunks of data) so latency is a possible factor in your throughput.

 

Well it only took two months but I finally got enough free time to get to do the test. It's rather inconclusive.

I ran hrping 5 times on WiFi pinging NAS server and ended up with average of those tests 2,86 ms. Then I ran the test 5 times while connected via Ethernet cable and that gave an average of 1,87 ms.
I realize that Wi-Fi latency is +50% but how does that translate into a non-speculative answer?

I'm thinking of introducing some traffic to increase latency and see if that has measurable effect.

 

This is probably a question best put to the developers - but my best guess is that the local decryption throughput is dependent on the round trip latency of your medium. Maybe there are some cache tunables on the container level?