VIA padlock performance

[Oliver Fromme]

Michael Reifenberger <mike at reifenberger.com> wrote:
 > with a via epia EN-15000 MB and an U160 scsi disk I get with eli(4) I get
 > ~27-40MB/s read/write performance trough eli(4) with AES265 key.
 > 
 > cryptotest gives:
 > (totum)(root) ./cryptotest -a aes256 100000 4096
 >   7.838 sec,  200000 aes256 crypts,    4096 bytes, 104511751 byte/sec,   797.4 
 > Mb/sec

Quite cool.

On my EPIA 10000 (1GHz VIA Nehemia) I did some performance
testing a few months ago under RELENG_6 (not sophisticated
enough to call it benchmarking).  For testing I used scp(1)
of a large file (an ISO9660 image, 213 MBytes), because
that's what I often need to do, so it's an important thing
for me.  These are the results (averages of several runs):

A - No padlock(4) loaded:

       213 MB in 56 seconds (3.8 MB/s)

          37.5 s user (67%)
          10.0 s sys  (18%)
           8.5 s int  (15%)
           0.0 s idle ( 0%)

B - With padlock loaded, no bandwidth limit:

       213 MB in 33 seconds (6.5 MB/s)

           8.0 s user (24%)
          16.0 s sys  (48%)
           9.0 s int  (27%)
           0.0 s idle ( 0%)

C - With padlock loaded, bandwidth limited:

       213 MB in 58 seconds (3.7 MB/s)

           7.5 s user (13%)
          14.5 s sys  (25%)
           7.0 s int  (12%)
          29.0 s idle (50%)

As you can see, the throughput of scp was almost doubled
when padlock(4) was enabled (from 3.8 MB/s to 6.5 MB/s).
The time spent in user mode drops to about a fifth, while
the "sys" time increases by 60%, which is to be expected
(caused by the overhead of setting up and running the
padlock engine).  The interrupt time doesn't change at
all.

I did a third test where I limited the bandwith (Dummynet)
to about the same value that was reached during the first
test.  Now the throughput was the same as in the first
test (of course), but the CPU was 50% idle and available
for other tasks.

The other side of the test was a 1.6 GHz Pentium-M which
had the test file in a large RAM disk, so the bottleneck
was clearly the EPIA system.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

Perl is worse than Python because people wanted it worse.
        -- Larry Wall