I wish to use a 2010 vintage quad core Xeon server to periodically encrypt 500GB eSATA drives. I have three questions:
1) I assume the current version of WDE is fully multi-threaded and throughput scales roughly linearly with the number of cores?
2) Am I able to restrict the number of cores utilised by the WDE process so as not to impact other work on the server?
3) Roughly how long should I expect each encryption to take?
There seems to be conflicting information around on the threading of WDE, even on the PGP KB site where I also asked this question (it is nearly dead there though) as a lot of older answers indicate that it is not offered.
Assuming your eSATA drives can deliver close to standard SATA speeds and you are using 7200 RPM drives we're looking at sustaining around 80-100MB/sec across the whole drive under ideal conditions.
I don't have any specifics about PGP but benchmarks of AES encryption speeds in the range of 100-150MByte / sec per core for 2008 era CPU's (3Ghz Core Duo) are pretty easy to find [ e.g. this slashdot comment indicating 600-700Mhz of a 2.13 Ghz Pentium M to handle 30Meg/sec ] and I've seen similar rates for much older CPU's so I'm taking that as a baseline. Given that you are running on substantially better CPUs than those I have no doubt that a single core on your server will easily handle the maximum throughput of a single eSATA drive.
PGP WDE is block based which should help throughput reach those rates for a conversion but whether that is actually true depends entirely on how they implement it and I've no idea whether they have done it well. In any case the best result you could get would be a full read of the drive at an average of 100Meg/sec (sequentially reading block by block) and then a full write of the drive (sequentially writing block by block). For a 500GB drive that would be 1,000 seconds or about 17 minutes. That wont saturate a single core on your server, even allowing for CPU overhead for the drive IO.
The balance of probability is that PGP WDE's conversion algorithm does not handle IO as efficiently as I assumed above so the time taken to encrypt the drive will be substantially longer - you will need to test it to be certain but I wouldn't be surprised if it was an order of magnitude slower and the CPU overhead for the encryption tasks will be proportionately lower too.
One final note if you are using a Westmere class CPU (Xeon 56xx) then PGP WDE supports the new AES-NI instructions that should deliver a better than 50% real world performance boost - see this Toms Hardware article where they show the benefits for Bitlocker but the PGP WDE benefit should be at least as good.
Edited to add:
I feel that I wasn't really clear in the above - multi-threading isn't going to help you as far as converting a single drive is concerned. It might help a little if you plan to run multiple drives in parallel but unless you have hardware that can handle many drives concurrently the IO limitations of the drives will be a significantly larger bottleneck than CPU utilization. The anecdotal evidence on the web [ here and here for example ] about the conversion speed ranges from 25 to 50GB per hour - I'd expect a decent eSATA drive to be faster than those examples but it seems unlikely that it would be much better than 100GB an hour.
Finally there is a very good discussion on the cpu overhead of disk encryption in general in the comments on this PGP Blog post that reinforces the point that the CPU is not the main bottleneck, Read\Write latencies are the main problem.
A few obvious searches on Google didn't turn up any hard answers to your questions about this specific product, so here's an estimate:
1) No idea if PGP is multithreaded but if it is, you should expect 50-80% increase in processing per extra core/CPU. 4 cores only give you 400% performance for some very, very specific workloads - and waiting around on data from disk that needs to be written back isn't one of them.
2) Task Manager lets you set CPU priorities on running processes, so that's at least one option.
3) I strongly suspect there will be very little overhead. Any recent Xeon CPU can do encryption faster than some random mechanical disks can write over USB 2.0. Which CPU is it, exactly? You can see here which ones have hardware support for encryption (AES-NI):
http://en.wikipedia.org/wiki/Xeon
If you are in a position to change tools, have a look at Truecrypt
1) Truecrypt is highly parallelized and scales about linearly
2) You can specify the number of cores to use
3) As to speed, it will depend on how you connect the drive, the number of cores you can spare, the encryption algorithms used etc. Given the hardware you have, disk io will likely be the bottleneck, even with a sata connection. But download it and run the benchmark, or encrypt a drive and see for yourself. (There's a portable mode, so you needn't even install it).