Re: Simple BDE disc encryption benchmark

Daniel Eriksson wrote:

> Hi! I just ran a very simple benchmark on the GBDE disc encryption in
> CURRENT. The benchmark setup looked like this:
> 
> * Slow machine (Celeron 366, 128MB mem)
> * 5-CURRENT from yesterday, running off of some old ATA disc
> * 2 x 9GB 10k rpm SCSI discs hooked up to an Adaptec 2940
> 
> The benchmark was to copy the /usr directory (copied from the ATA disc,
> 1.7GB) or a directory containing big files (/bigfiles, 1.7GB in 16 files
> created by 'dd if=/dev/random ...') from scsi disc 1 to scsi disc 2. I ran
> each benchmark twice and took a simple average of the results.
> 
> unencrypted to unencrypted:
> /usr     :  697 real        10.6 user       235 sys  (~50% idle)
> /bigfiles:  123 real         0.4 user        84 sys  (~25% idle)
> 
> unencrypted to encrypted:
> /usr     : 1778 real        10.7 user       236 sys  (~35% idle)
> /bigfiles:  379 real         0.4 user        82 sys  (~10% idle)
> 
> encrypted to encrypted:
> /usr     : 1978 real        11.6 user       242 sys  (~25% idle)
> /bigfiles:  615 real         0.4 user        80 sys  (0% idle)
> 
> The only time the CPU was completely busy was when copying /bigfiles from
> encrypted to encrypted.
> 
> My question is: Why does the it take so much longer when encryption is
> involved even though 'top' seems to think there are CPU cycles left to burn?

The problem (well, not quite "the problem" since it is design decision) 
is that GBDE tries to rearrange sectors in pseudo-random fashion to make 
cryptoanalysis harder. Usually filesystem tries to place all sectors 
that belong to the same file consequently, to avoid expensive disk 
seeks. But on encrypted disk logically ajaced sectors are physically 
spread, so that reading them introduces seek delays.

-Maxim