Skip Navigation CECS Home | ANU Home | Search ANU

COMP8320 Laboratory 06 - week 06, 2011

Role of the Operating System and Cryptographic Accelerators

This session will provide some experience in utilities that demonstrate the role of the operating system in multicore computing. Later, it will give you an understanding of how the T2's cryptograhics accelerators are utilized the the Solaris Cryptographic Framework, using system-level tools.

Part 1: System-level Monitoring

Log into wallaman with 2 terminal windows.

1. The command prstat is the Solaris equivalent of the Linux top command. Do man prstat to find the parameters to update the process information every second and execute this command in one of your windows. Then launch a reasonably long running parallel program, say linpack 4000, with 16 threads. Observe the PROCESS/NLWP column confirming that your process is indeed using 16 threads (LWP (LightWeight Process) is the Solaris name for a kernel-level thread).

   Observe now the TIME and CPU columns. What do these quantities actually refer to? (hint: compare with the running time of the program via time linpack 4000, and/or read the man page).

   Run the parallel program again, and observe the CPU column. What does this actually tell you? Is it always the same?

   Exit prstat by typing q.

2. Compare the output of time linpack 4000 and time linpack -v 1 4000 with (say) 32 threads. What do you observe about the system time in each of them? What could be the possible cause? (hint: see Lecture 6).

3. The command mpstat gives per-CPU statistics; read the man page to find information about its usage and output fields. Make sure one of your windows at least 56 lines long. In that window, run the command mpstat 1 | tee tmp. In your other window, immediately run your 16-thread parallel program (export OMP_NUM_THREADS=16; time linpack 4000). Type Ctrl-C in the mpstat window as soon as the parallel program terminates.

   Inspect now the file tmp. The first set of data indicates various statistics since boot time. Which vCPUs have fielded the most interrupts? context switches? performed the most system calls? Identify the patterns across the hierarchy of processor groups (as defined in Lecture 6).

   Now scroll down till you see a change in this pattern. Which vCPU was allocated the master thread for your parallel program? What is the ratio of user and system time before your program enters the main parallel region? Scroll further down till the pattern changes again, indicating the parallel region. What is the ratio of user and system time for the other threads; is this what you expect? Observe what CPUs are being scheduled; are the threads spread evenly (as possible) per cores and across groups within each core? Is the operating system favoring (or otherwise) the vCPUs fielding the most interrupts?

   Repeat the above for 8, 32 and 56 threads, observing in particular the scheduling behavior for the master thread and once the parallel region begins. You will probably notice a qualitative change in behavior (user, system and idle time) at 56 threads; does the number of interrupts, context switches and migrations correlate with this?

   Note: in a laboratory situation with several people doing this at once, it might not be obvious which vCPUs are being utilized by your process. We may need to spread this part out a little. Or you could try again a bit later when the machine is more idle. On the other hand, note that behaviors such as interrupts, context switching etc become less marked if the system only has one active user.

   Finally, with 8 threads, repeat the above for time linpack -c c 2000, for c = 1, 2, 4. Check that the cores you expect to be used are in fact being used. Is the number of context switches, interrupts, system calls and idle time being affected by placement? What differences do you see in the real and system times reported?

   Note: if you have not yet implemented core placement in linpack, cd to your lab04/scalable_lock directory and use time ./locktest 8 1000000 20 0 c, for c = 1, 2, 4 instead.

4. Other useful operating system commands are vmstat and iostat. These indicate operating system performance when running under memory-limited and I/O bound workloads.

Part 2: T2 Cryptographic Accelerators

1. OpenSSL is the defacto-standard protocol for supporting secure transactions, such as is used in e-Commerce. The openssl utility provides benchmarking facilities for all major cryptographic algorithms used. The Solaris version has an pkcs11 engine which accesses the Solaris Cryptographic Framework. This is currently configured on wallaman to use the T2 Cryptographic Accelerators - provided the pkcs11 library decides it is worthwhile to do so. Verify that the openssl utility has this engine using the command:
   openssl engine -c
   Now check the status of the cryptographic providers on wallaman:
   /usr/sbin/cryptoadm list -p
   We will now try some of the algorithms that it can support. The command kstat prints kernel-level statistics for various `modules' (including the pseudo-devices for the accelerators, NCP (access the MAU) and N2CP (access the SPU)). We will first try the rsa algorithm. Put the name of the algorithm in a shell variable
   a=rsa
   and execute the commands (cut-and-paste all 3 lines together)::
   (kstat -m ncp; kstat -m n2cp) > cs1; time openssl speed -engine pkcs11 $a
   (kstat -m ncp; kstat -m n2cp) > cs2; time openssl speed $a ; (kstat -m ncp; kstat -m n2cp) > cs3
   echo done!
   Observe both the speeds of the operation (summary of the last few lines of output) for each; note the differences in speeds when libpcsk11 (and hopefully the accelerators) are used and when it is not (standard user-level algorithms are employed). Note also the differences in user and system times.

   Inspect the file cs1; what counters can you see? Which of the 2 units performs RSA?

   echo "differing cyptostats with pkcs11:"; diff cs1 cs2
   echo "differing cyptostats without pkcs11"; diff cs2 cs3
   Which unit (MAU or SPU) gets used for the algorithm? How many units are being used? What is the counter corresponding to the algorithm?

   Note again: in a laboratory situation with several people doing this at once, you may see changes in the stats, as they are system-level, due to someone else's activity.

   Repeat the above for a=md5, a="-evp aes-128-cbc", a="-evp des-ede3-cbc" instead of a=rsa (if you are really keen/curious/have time, you could also check a=dsa, a="-evp des-cbc", a=sha1 and a=hmac). What are the `cutoff' points where pkcs11 gives superior performance in each case?

2. A further comparison would be with the crypto units disabled. Unfortunately this has to be done on a system-wide basis, and requires root privilege. Click here for the results. Note that it was only possible to disable the SPU (n2cp/0), so only results for algorithms fielded by the SPU are shown.

3. As a comparison in performance on another machine (x86 core @ 2.7 GHz), on partch repeat the above for:
   time openssl speed $a
   How does T2+crypto, single strand T2, and single core X86 performance compare?

   Use the openssl engine -c command to find out the name of the (off-chip) accelerator on partch. Try the benchmarks again with this `engine' enabled. How does the performance compare now?

4. In Q1, the performance, differences in user/system time and kernel statistics indicate the crypto accelerators are being used. A more direct indicator would be whether the T2's crypto performance counters:
   MD5_SHA-1_SHA-256_op DES_3DES_op AES_op RC4_op MA_op
   tick over when we run these benchmarks. Try using the cputrack command:
   cputrack -cAES_op,hpriv openssl speed -engine pkcs11 -evp aes-128-cbc
   However, from the primary domain, we can get access to the counters (Q: why do we have to specify hpriv to get the counts?). Click here for the results. Note that the primary domain has at this time only one core and hence one MAU/SPU available. For some algorithms, you will notice that the kernel only decides to use the accelerator for large keys. Why do you think this is? Note that we have not yet discovered any benchmark which makes the MAU_op or RC4_op counters tick over (possibly these counters do not work).

5. Copy the files for the following part into your home directory:
   cp -pr /dept/dcs/comp8320/public/lab06/ .
   cd to lab06. Inspect the file aes11.c and indentify the pkcs11 call that performs the encryption for the AES algorithm. Type the command make, and run the program:
   time ./t2accel -a aes
   To see the interaction of the pkcs11 library with the CRYPTO ioctls (system calls), we will perform a trace on the library and system calls:
   OMP_NUM_THREADS=1; truss -o libpkcs11.aes.truss -u libpkcs11 ./t2accel -a aes -r 10
   Goto the end of the file and search backwards for the sequence of calls (there should be 10) of the encryption function. What ioctl is invoked by the function? What other cyrpto-related ioctls are invoked when the program runs?

   An interesting aspect of the program is that it can perform the cryptographic operations in threaded mode. Inspect aes11.c to see how this is done. See what kind of speedups are possible:

   for p in 1 2 4 8 16; do time ./threadrun $p ./t2accel -a aes; done
   for p in 1 2 4 8 16; do time ./threadrun $p ./t2accel -a rsa; done
   (other algorithms supported by the program are des, des3, md5, sha1 and sha256). Why might the speedups vary for different algorithms?

Appendix: OpenSSL Benchmarks with Crypto Units Disabled

root@wallaman:~> cryptoadm disable provider=n2cp/0 all
root@wallaman:~> cryptoadm disable provider=ncp/0 all
cryptoadm: failed to update configuration - no driver package information.
root@wallaman:~> cryptoadm list -p
...
Kernel hardware providers:
==========================

n2cp/0: all mechanisms are enabled, except
CKM_DES_CBC,CKM_DES_ECB,CKM_DES3_CBC,CKM_DES3_ECB,CKM_AES_CBC,CKM_AES_ECB,
CKM_AES_CTR,CKM_RC4,CKM_MD5,CKM_SHA_1,CKM_SHA256,CKM_MD5_HMAC,CKM_SHA_1_HMAC,
CKM_SHA256_HMAC,CKM_MD5_HMAC_GENERAL,CKM_SHA_1_HMAC_GENERAL,
CKM_SHA256_HMAC_GENERAL,CKM_SSL3_MD5_MAC,CKM_SSL3_SHA1_MAC.
ncp/0: all mechanisms are enabled.
n2rng/0: all mechanisms are enabled. random is enabled.

root@wallaman:~> time openssl speed -engine pkcs11 md5
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5                406.74k     1575.22k     5751.68k    18939.55k   130211.52k
13.31u 1.73s 0:15.11 99.5%

root@wallaman:~> time openssl speed -engine pkcs11 -evp aes-128-cbc
engine "pkcs11" set.
Doing aes-128-cbc for 3s on 16 size blocks: 648933 aes-128-cbc's in 3.00s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc       3605.82k     5618.41k     7985.07k     9262.08k     9712.98k
15.02u 0.01s 0:15.11 99.4%

root@wallaman:~> time openssl speed -engine pkcs11 -evp des-ede3-cbc
engine "pkcs11" set.
...
Doing des-ede3-cbc for 3s on 16 size blocks: 369473 des-ede3-cbc's in 2.99s
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
des-ede3-cbc      1977.11k     3081.86k     3667.71k     3888.13k     3970.39k
15.02u 0.01s 0:15.10 99.5%

root@wallaman:~> time openssl speed -engine pkcs11 -evp des-cbc
engine "pkcs11" set.
Doing des-cbc for 3s on 16 size blocks: 516162 des-cbc's in 3.00s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
des-cbc           2752.86k     4868.97k     6416.81k     7117.82k     7370.07k
15.02u 0.01s 0:15.11 99.4%

root@wallaman:~> time openssl speed -engine pkcs11 sha1
engine "pkcs11" set.
Doing sha1 for 3s on 16 size blocks: 67894 sha1's in 2.73s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1               397.91k     1513.54k     5317.13k    19598.63k   133200.65k
13.36u 1.68s 0:15.11 99.5%

root@wallaman:~> time openssl speed -engine pkcs11 hmac
engine "pkcs11" set.
Doing hmac(md5) for 3s on 16 size blocks: 35613 hmac(md5)'s in 2.93s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
hmac(md5)          194.47k      768.59k     2934.51k    10387.71k    75307.89k
14.41u 0.62s 0:15.10 99.5%

root@wallaman:~> cryptoadm enable provider=n2cp/0 all
root@wallaman:~> date
Monday, 29 August 2011 12:33:15 PM EST

Appendix: OpenSSL Benchmarks under cputrack on the Primary Domain

cstguard@mavericks:~/crypto> cputrack -cMD5_SHA-1_SHA-256_op,hpriv openssl speed -engine pkcs11 md5
   time lwp      event      pic0 
engine "pkcs11" set.
Doing md5 for 3s on 16 size blocks:   1.017   1       tick         0 
  2.017   1       tick         0 
  3.017   1       tick         0 
56346 md5's in 2.57s
Doing md5 for 3s on 64 size blocks:   4.017   1       tick         0 
  5.017   1       tick         0 
  6.017   1       tick         0 
54752 md5's in 2.58s
Doing md5 for 3s on 256 size blocks:   7.017   1       tick         0 
  8.017   1       tick         0 
  9.017   1       tick         0 
50483 md5's in 2.61s
Doing md5 for 3s on 1024 size blocks:  10.017   1       tick      9181 
 11.017   1       tick     10097 
 12.017   1       tick     10104 
30477 md5's in 1.51s
Doing md5 for 3s on 8192 size blocks:  13.017   1       tick      8106 
 14.017   1       tick      7996 
 15.017   1       tick      7841 
23697 md5's in 1.40s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5                350.79k     1358.19k     4951.59k    20667.85k   138661.30k
 15.134   1       exit     54174 

cstguard@mavericks:~/crypto> cputrack -cAES_op,hpriv openssl speed -engine pkcs11 -evp aes-128-cbc
   time lwp      event      pic0 
engine "pkcs11" set.
Doing aes-128-cbc for 3s on 16 size blocks:   1.019   1       tick     22998 
  2.019   1       tick     28993 
  3.019   1       tick     28866 
87615 aes-128-cbc's in 0.82s
Doing aes-128-cbc for 3s on 64 size blocks:   4.019   1       tick     28956 
  5.019   1       tick     28904 
  6.019   1       tick     26908 
87468 aes-128-cbc's in 0.82s
Doing aes-128-cbc for 3s on 256 size blocks:   7.019   1       tick     26742 
  8.019   1       tick     28152 
  9.019   1       tick     28145 
85165 aes-128-cbc's in 0.80s
Doing aes-128-cbc for 3s on 1024 size blocks:  10.019   1       tick     25441 
 11.019   1       tick     25104 
 12.019   1       tick     25198 
75384 aes-128-cbc's in 0.71s
Doing aes-128-cbc for 3s on 8192 size blocks:  13.019   1       tick     16375 
 14.019 
 14.019   1       tick     15210 
 15.019   1       tick     15187 
45491 aes-128-cbc's in 0.43s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial) blowfish(ptr) 
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc       1709.56k     6826.77k    27252.80k   108722.84k   866656.45k
 15.147   1       exit    372837 

cstguard@mavericks:~/crypto> cputrack -cDES_3DES_op,hpriv openssl speed -engine pkcs11 -evp des-ede3-cbc
   time lwp      event      pic0 
engine "pkcs11" set.
Doing des-ede3-cbc for 3s on 16 size blocks:   1.021   1       tick     25830 
  2.021   1       tick     29049 
  3.021   1       tick     29236 
86970 des-ede3-cbc's in 0.82s
Doing des-ede3-cbc for 3s on 64 size blocks:   4.021   1       tick     28977 
  5.021   1       tick     28861 
  6.021   1       tick     29007 
86830 des-ede3-cbc's in 0.83s
Doing des-ede3-cbc for 3s on 256 size blocks:   7.021   1       tick     28098 
  8.021   1       tick     28261 
  9.021   1       tick     28028 
84295 des-ede3-cbc's in 0.80s
Doing des-ede3-cbc for 3s on 1024 size blocks:  10.021   1       tick     24591 
 11.021   1       tick     24366 
 12.021   1       tick     24389 
72987 des-ede3-cbc's in 0.69s
Doing des-ede3-cbc for 3s on 8192 size blocks:  13.021   1       tick     14764 
 14.021   1       tick     13785 
 15.021   1       tick     14169 
41672 des-ede3-cbc's in 0.39s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
...
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
des-ede3-cbc      1696.98k     6695.33k    26974.40k   108316.94k   875325.70k
 15.142   1       exit    372759 

cstguard@mavericks:~> cputrack -c DES_3DES_op,hpriv openssl speed -engine pkcs11 -evp des-cbc
   time lwp      event      pic0 
engine "pkcs11" set.
Doing des-cbc for 3s on 16 size blocks:   1.016   1       tick     23628 
  2.016   1       tick     27744 
  3.016   1       tick     27864 
82804 des-cbc's in 0.83s
Doing des-cbc for 3s on 64 size blocks:   4.016   1       tick     27588 
  5.016   1       tick     26909 
  6.016   1       tick     27499 
81958 des-cbc's in 0.83s
Doing des-cbc for 3s on 256 size blocks:   7.016   1       tick     26814 
  8.016   1       tick     26396 
  9.016   1       tick     26247 
79330 des-cbc's in 0.81s
Doing des-cbc for 3s on 1024 size blocks:  10.016   1       tick     24339 
 11.016   1       tick     23851 
 12.016   1       tick     24096 
71927 des-cbc's in 0.73s
Doing des-cbc for 3s on 8192 size blocks:  13.016   1       tick     16945 
 14.016   1       tick     15875 
 15.016   1       tick     15856 
47641 des-cbc's in 0.49s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
des-cbc           1596.22k     6319.65k    25072.20k   100894.86k   796479.74k
 15.153   1       exit    363665 


cstguard@mavericks:~/crypto> cputrack -cMD5_SHA-1_SHA-256_op,hpriv openssl speed -engine pkcs11 sha1
   time lwp      event      pic0 
engine "pkcs11" set.
Doing sha1 for 3s on 16 size blocks:   1.020   1       tick         0 
  2.020   1       tick         0 
  3.020   1       tick         0 
56233 sha1's in 2.57s
Doing sha1 for 3s on 64 size blocks:   4.020   1       tick         0 
  5.020   1       tick         0 
  6.020   1       tick         0 
53816 sha1's in 2.60s
Doing sha1 for 3s on 256 size blocks:   7.020   1       tick         0 
  8.020   1       tick         0 
  9.020   1       tick         0 
48753 sha1's in 2.63s
Doing sha1 for 3s on 1024 size blocks:  10.020   1       tick      8594 
 11.020   1       tick     10503 
 12.020   1       tick     10520 
31494 sha1's in 1.49s
Doing sha1 for 3s on 8192 size blocks:  13.020   1       tick      8371 
 14.020   1       tick      7913 
 15.020   1       tick      7893 
23718 sha1's in 1.34s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1               350.09k     1324.70k     4745.54k    21644.20k   144998.40k
 15.215   1       exit     55212 

cstguard@mavericks:~> cputrack -c MD5_SHA-1_SHA-256_op,hpriv openssl speed -engine pkcs11 hmac
   time lwp      event      pic0 
engine "pkcs11" set.
Doing hmac(md5) for 3s on 16 size blocks:   1.015   1       tick         0 
  2.015   1       tick         0 
  3.015   1       tick         0 
26163 hmac(md5)'s in 2.81s
Doing hmac(md5) for 3s on 64 size blocks:   4.015   1       tick         0 
  5.015   1       tick         0 
  6.015   1       tick         0 
25890 hmac(md5)'s in 2.83s
Doing hmac(md5) for 3s on 256 size blocks:   7.015   1       tick         0 
  8.015   1       tick         0 
  9.015   1       tick         0 
25547 hmac(md5)'s in 2.82s
Doing hmac(md5) for 3s on 1024 size blocks:  10.015   1       tick      5526 
 11.015   1       tick      6394 
 12.015   1       tick      6369 
19168 hmac(md5)'s in 2.06s
Doing hmac(md5) for 3s on 8192 size blocks:  13.015   1       tick      5401 
 14.015   1       tick      5227 
 15.015   1       tick      5270 
15747 hmac(md5)'s in 1.86s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
hmac(md5)          148.97k      585.50k     2319.16k     9528.17k    69354.53k
 15.162   1       exit     34915 

cstguard@mavericks:~/crypto> cputrack -T 10 -cMA_op,hpriv openssl speed -engine pkcs11 rsa
   time lwp      event      pic0 
engine "pkcs11" set.
Doing 512 bit private rsa's for 10s:  10.020   1       tick         0 
27328 512 bit private RSA's in 1.13s
Doing 512 bit public rsa's for 10s:  20.020   1       tick         0 
46091 512 bit public RSA's in 1.63s
Doing 1024 bit private rsa's for 10s:  30.020   1       tick         0 
13684 1024 bit private RSA's in 0.59s
Doing 1024 bit public rsa's for 10s:  40.020   1       tick         0 
28576 1024 bit public RSA's in 1.03s
Doing 2048 bit private rsa's for 10s:  50.021   1       tick         0 
3737 2048 bit private RSA's in 0.17s
Doing 2048 bit public rsa's for 10s:  60.020   1       tick         0 
12462 2048 bit public RSA's in 0.45s
Doing 4096 bit private rsa's for 10s:  70.090   1       tick         0 
13 4096 bit private RSA's in 10.28s
Doing 4096 bit public rsa's for 10s:  80.042   1       tick         0 
426 4096 bit public RSA's in 10.00s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
...
                  sign    verify    sign/s verify/s
rsa  512 bits   0.0000s   0.0000s  24184.1  28276.7
rsa 1024 bits   0.0000s   0.0000s  23193.2  27743.7
rsa 2048 bits   0.0000s   0.0000s  21982.4  27693.3
rsa 4096 bits   0.7908s   0.0235s      1.3     42.6
 81.246   1       exit         0 

cstguard@mavericks:~> cputrack -T 10 -c MA_op,hpriv openssl speed -engine pkcs11 dsa
   time lwp      event      pic0 
engine "pkcs11" set.
Doing 512 bit sign dsa's for 10s:  10.014   1       tick         0 
13780 512 bit DSA signs in 0.91s
Doing 512 bit verify dsa's for 10s:  20.014   1       tick         0 
11028 512 bit DSA verify in 0.76s
Doing 1024 bit sign dsa's for 10s:  30.014   1       tick         0 
10564 1024 bit DSA signs in 0.72s
Doing 1024 bit verify dsa's for 10s:  40.014   1       tick         0 
7146 1024 bit DSA verify in 0.51s
Doing 2048 bit sign dsa's for 10s:  50.023   1       tick         0 
216 2048 bit DSA signs in 10.01s
Doing 2048 bit verify dsa's for 10s:  60.080   1       tick         0 
122 2048 bit DSA verify in 9.99s
...
                  sign    verify    sign/s verify/s
dsa  512 bits   0.0001s   0.0001s  15142.9  14510.5
dsa 1024 bits   0.0001s   0.0001s  14672.2  14011.8
dsa 2048 bits   0.0463s   0.0819s     21.6     12.2
 60.333   1       exit         0 

cstguard@mavericks:~/crypto> cputrack -cRC4_op,hpriv openssl speed -engine pkcs11 rc4
   time lwp      event      pic0 
engine "pkcs11" set.
Doing rc4 for 3s on 16 size blocks:   1.063   1       tick         0 
  2.073   1       tick         0 
  3.103   1       tick         0 
4996711 rc4's in 2.97s
Doing rc4 for 3s on 64 size blocks:   4.123   1       tick         0 
  5.153   1       tick         0 
  6.023   1       tick         0 
1323951 rc4's in 3.00s
Doing rc4 for 3s on 256 size blocks:   7.023   1       tick         0 
  8.023   1       tick         0 
  9.033   1       tick         0 
335062 rc4's in 2.99s
Doing rc4 for 3s on 1024 size blocks:  10.043   1       tick         0 
 11.053   1       tick         0 
 12.063   1       tick         0 
84251 rc4's in 3.00s
Doing rc4 for 3s on 8192 size blocks:  13.073   1       tick         0 
 14.083   1       tick         0 
 15.093   1       tick         0 
10560 rc4's in 2.99s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4              26918.31k    28244.29k    28687.58k    28757.67k    28932.28k
 15.129   1       exit         0 

Copyright | Disclaimer | Privacy | Contact ANU