|
Description
|
at present, the speed-up of SunSSH on T2 platform is limited by the size of the buffers used. It looks like the mostly used buffer in bulk data transfer is 16KB. The way how SunSSH client/server work is that they process what they get, not waiting for a certain amount of data to come (think an interactive session).
what we could do for AES-CTR mode is that we could encrypt/decrypt large chunks of zeros in advance, say in 64-128KB chunks, and then XOR the data against such precomputed sequence. When we need more data, we process another chunk of zeroes. The encryption/decryption would be independent on the buffer size, pipe limits, network latency or packet fragmentation.
we probably might get another decent speed-up from this. Just a short example, when using 16KB byte long chunks, and the PKCS#11 API directly (the program uses AES-CBC but that's not relevant for the test), we see it can do 140MB/s:
-bash-3.2$ ./pk11aesperf -c 1 -n 30000 -s 16384 -S 0
Overall Throughput:
===================
Finished 30000 ops in 3562002049 nanosecs (3562.00 ms)
Data Rate: 8422.23 ops/sec 137989817.66 bytes/second
Using: 1 children (each 30000 operations)
when we increase the block size to 64KB we see that we can do 220MB/s:
-bash-3.2$ ./pk11aesperf -c 1 -n 6000 -s 65536 -S 0
Overall Throughput:
===================
Finished 6000 ops in 1783803078 nanosecs (1783.80 ms)
Data Rate: 3363.60 ops/sec 220436885.59 bytes/second
Using: 1 children (each 6000 operations)
And with 128KB chunks it's 240MB/s. We can't say we would see ~50% speed-up since symmetric crypto is not 100% of what SSH does but the numbers are promising regardless.
|