freeswan/doc/performance.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <HTML>
   3 <HEAD>
   4 <TITLE> Introduction to FreeS/WAN</TITLE>
   5 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   6 </HEAD>
   7 <BODY>
   8 <A HREF="toc.html">Contents</a>
   9 <A HREF="faq.html">Previous</a>
  10 <HR>
  11 <H1><A name="performance">Performance of FreeS/WAN</A></H1>
  12  The performance of FreeS/WAN is adequate for most applications.
  13 Perhaps because of that, there are few detailed measurements. Those we
  14 know of are below.
  15 <P> The University of Wales at Aberystwyth has done quite detailed
  16  tests and put <A href="http://tsc.llwybr.org.uk/public/reports/SWANTIME/">
  17 their  results</A> on the web.</P>
  18 <P><EM> Even a 486 can handle a T1 line</EM>, according to this mailing
  19  list message:</P>
  20 <PRE>Subject: Re: linux-ipsec: IPSec Masquerade
  21    Date: Fri, 15 Jan 1999 11:13:22 -0500
  22    From: Michael Richardson
  23
  24 . . . A 486/66 has been clocked by Phil Karn to do
  25 10Mb/s encryption.. that uses all the CPU, so half that to get some CPU,
  26 and you have 5Mb/s. 1/3 that for 3DES and you get 1.6Mb/s....</PRE>
  27 <P>and a piece of mail from project technical lead Henry Spencer:</P>
  28 <PRE>Oh yes, and a new timing point for Sandy's docs...  A P60 -- yes, a 60MHz
  29 Pentium, talk about antiques -- running a host-to-host tunnel to another
  30 machine shows an FTP throughput (that is, end-to-end results with a real
  31 protocol) of slightly over 5Mbit/s either way.  (The other machine is much
  32 faster, the network is 100Mbps, and the ether cards are good ones... so
  33 the P60 is pretty definitely the bottleneck.)</PRE>
  34 <P> Here is some additional data from the mailing list. </P>
  35 <PRE>
  36 Subject: FreeSWAN (specically KLIPS) performance measurements
  37    Date: Thu, 01 Feb 2001
  38    From: Nigel Metheringham &lt;Nigel.Metheringham@intechnology.co.uk&gt;
  39
  40
  41 I've spent a happy morning attempting performance tests against KLIPS
  42 (this is due to me not being able to work out the CPU usage of KLIPS so
  43 resorting to the crude measurements of maximum throughput to give a
  44 baseline to work out loading of a box).
  45
  46 Measurements were done using a set of 4 boxes arranged in a line, each
  47 connected to the next by 100Mbit duplex ethernet.  The inner 2 had an
  48 ipsec tunnel between them (shared secret, but I was doing measurements
  49 when the tunnel was up and running - keying should not be an issue
  50 here).  The outer pair of boxes were traffic generators or traffic sink.
  51
  52 The crypt boxes are Compaq DL380s - Uniprocessor PIII/733 with 256K
  53 cache.  They have 128M main memory.  Nothing significant was running on
  54 the boxes other than freeswan.  The kernel was a 2.2.19pre7 patched
  55 with freeswan and ext3.
  56
  57 Without an ipsec tunnel in the chain (ie the 2 inner boxes just being
  58 100BaseT routers), throughput (measured with ttcp) was between 10644
  59 and 11320 KB/sec
  60
  61 With an ipsec tunnel in place, throughput was between 3268 and 3402
  62 KB/sec
  63
  64 These measurements are for data pushed across a TCP link, so the
  65 traffic on the wire between the 2 ipsec boxes would have been higher
  66 than this....
  67
  68 vmstat (run during some other tests, so not affecting those figures) on
  69 the encrypting box shows approx 50% system 50% idle CPU - which I
  70 don't believe at all.  Interactive feel of the box was significantly
  71 sluggish.
  72
  73 I also tried running the kernel profiler (see man readprofile) during
  74 test runs.
  75
  76 A box doing primarily decrypt work showed basically nothing happening -
  77 I assume interrupts were off.
  78 A box doing encrypt work showed the following:-
  79  Ticks Function                                   Load
  80  ~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ~~~~~~
  81    956 total                                      0.0010
  82    532 des_encrypt2                               0.1330
  83    110 MD5Transform                               0.0443
  84     97 kmalloc                                    0.1880
  85     39 des_encrypt3                               0.1336
  86     23 speedo_interrupt                           0.0298
  87     14 skb_copy_expand                            0.0250
  88     13 ipsec_tunnel_start_xmit                    0.0009
  89     13 Decode                                     0.1625
  90     11 handle_IRQ_event                           0.1019
  91     11 .des_ncbc_encrypt_end                      0.0229
  92     10 speedo_start_xmit                          0.0188
  93      9 satoa                                      0.0225
  94      8 kfree                                      0.0118
  95      8 ip_fragment                                0.0121
  96      7 ultoa                                      0.0365
  97      5 speedo_rx                                  0.0071
  98      5 .des_encrypt2_end                          5.0000
  99      4 _stext                                     0.0140
 100      4 ip_fw_check                                0.0035
 101      2 rj_match                                   0.0034
 102      2 ipfw_output_check                          0.0200
 103      2 inet_addr_type                             0.0156
 104      2 eth_copy_and_sum                           0.0139
 105      2 dev_get                                    0.0294
 106      2 addrtoa                                    0.0143
 107      1 speedo_tx_buffer_gc                        0.0024
 108      1 speedo_refill_rx_buf                       0.0022
 109      1 restore_all                                0.0667
 110      1 number                                     0.0020
 111      1 net_bh                                     0.0021
 112      1 neigh_connected_output                     0.0076
 113      1 MD5Final                                   0.0083
 114      1 kmem_cache_free                            0.0016
 115      1 kmem_cache_alloc                           0.0022
 116      1 __kfree_skb                                0.0060
 117      1 ipsec_rcv                                  0.0001
 118      1 ip_rcv                                     0.0014
 119      1 ip_options_fragment                        0.0071
 120      1 ip_local_deliver                           0.0023
 121      1 ipfw_forward_check                         0.0139
 122      1 ip_forward                                 0.0011
 123      1 eth_header                                 0.0040
 124      1 .des_encrypt3_end                          0.0833
 125      1 des_decrypt3                               0.0034
 126      1 csum_partial_copy_generic                  0.0045
 127      1 call_out_firewall                          0.0125
 128
 129 Hope this data is helpful to someone... however the lack of visibility
 130 into the decrypt side makes things less clear
 131 </PRE>
 132 <H2><A name="methods">Methods of mesasuring</A></H2>
 133  If you want to measure the loads FreeS/WAN puts on a system, note that
 134 tools such as top or measurements such as load average are more-or-less
 135 useless for this. They are not designed to measure something that does
 136 most of its work inside the kernel.
 137 <P> Here is a message from FreeS/WAN kernel programmer Richard Guy
 138 Briggs on this: </P>
 139 <PRE>
 140 &gt; I have a batch of boxes doing Freeswan stuff.
 141 &gt; I want to measure the CPU loading of the Freeswan tunnels, but am
 142 &gt; having trouble seeing how I get some figures out...
 143 &gt;
 144 &gt;  - Keying etc is in userspace so will show up on the per-process
 145 &gt;    and load average etc (ie pluto's load)
 146
 147 Correct.
 148
 149 &gt;  - KLIPS is in the kernel space, and does not show up in load average
 150 &gt;    I think also that the KLIPS per-packet processing stuff is running
 151 &gt;    as part of an interrupt handler so it does not show up in the
 152 &gt;    /proc/stat system_cpu or even idle_cpu figures
 153
 154 It is not running in interrupt handler.  It is in the bottom half.
 155 This is somewhere between user context (careful, this is not
 156 userspace!) and hardware interrupt context.
 157
 158 &gt; Is this correct, and is there any means of instrumenting how much the
 159 &gt; cpu is being loaded - I don't like the idea of a system running out of
 160 &gt; steam whilst still showing 100% idle CPU :-)
 161
 162 vmstat seems to do a fairly good job, but use a running tally to get a
 163 good idea.  A one-off call to vmstat gives different numbers than a
 164 running stat.  To do this, put an interval on your vmstat command
 165 line.
 166 </PRE>
 167  and another suggestion from the same thread:
 168 <PRE>
 169 Subject: Re: Measuring the CPU usage of Freeswan
 170    Date: Mon, 29 Jan 2001
 171    From: Patrick Michael Kane &lt;modus@pr.es.to&gt;
 172
 173 The only truly accurate way to accurately track FreeSWAN CPU usage is to use
 174 a CPU soaker. You run it on an unloaded system as a benchmark, then start up
 175 FreeSWAN and take the difference to determine how much FreeSWAN is eating.
 176 I believe someone has done this in the past, so you may find something in
 177 the FreeSWAN archives.  If not, someone recently posted a URL to a CPU
 178 soaker benchmark tool on linux-kernel.
 179 </PRE>
 180 <HR>
 181 <A HREF="toc.html">Contents</a>
 182 <A HREF="faq.html">Previous</a>
 183 </BODY>
 184 </HTML>