freeswan/doc/src/performance.html

   1 <html>
   2 <head>
   3   <meta http-equiv="Content-Type" content="text/html">
   4   <title>FreeS/WAN performance</title>
   5   <meta name="keywords"
   6   content="Linux, IPsec, VPN, security, FreeSWAN, performance, benchmark">
   7   <!--
   8
   9   Written by Sandy Harris for the Linux FreeS/WAN project
  10   Freely distributable under the GNU General Public License
  11
  12   More information at www.freeswan.org
  13   Feedback to users@lists.freeswan.org
  14
  15   CVS information:
  16   RCS ID:          $Id: performance.html,v 1.29 2002/03/26 16:44:09 sandy Exp $
  17   Last changed:    $Date: 2002/03/26 16:44:09 $
  18   Revision number: $Revision: 1.29 $
  19
  20   CVS revision numbers do not correspond to FreeS/WAN release numbers.
  21   -->
  22 </head>
  23
  24 <head>
  25   <title>FreeS/WAN performance</title>
  26 </head>
  27
  28 <body>
  29 <h1><a name="performance">Performance of FreeS/WAN</a></h1>
  30 The performance of FreeS/WAN is adequate for most applications.
  31
  32 <p>In normal operation, the main concern is the overhead for encryption,
  33 decryption and authentication of the actual IPsec (<a
  34 href="glossary.html#ESP">ESP</a> and/or <a href="glossary.html#AH">AH</a>)
  35 data packets. Tunnel setup and rekeying occur so much less frequently than
  36 packet processing that, in general, their overheads are not worth worrying
  37 about.</p>
  38
  39 <p>At startup, however, tunnel setup overheads may be significant. If you
  40 reboot a gateway and it needs to establish many tunnels, expect some delay.
  41 This and other issues for large gateways are discussed <a
  42 href="#biggate">below</a>.</p>
  43
  44 <h2><a name="pub.bench">Published material</a></h2>
  45
  46 <p>The University of Wales at Aberystwyth has done quite detailed speed tests
  47 and put <a href="http://tsc.llwybr.org.uk/public/reports/SWANTIME/">their
  48 results</a> on the web.</p>
  49
  50 <p>Davide Cerri's <a href="http://www.linux.it/~davide/doc/">thesis (in
  51 Italian)</a> includes performance results for FreeS/WAN and for <a
  52 href="glossary.html#TLS">TLS</a>. He posted an <a
  53 href="http://lists.freeswan.org/pipermail/users/2001-December/006303.html">English
  54 summary</a> on the mailing list.</p>
  55
  56 <p>Steve Bellovin used one of AT&amp;T Research's FreeS/WAN gateways as his
  57 data source for an analysis of the cache sizes required for key swapping in
  58 IPsec. Available as <a
  59 href="http://www.research.att.com/~smb/talks/key-agility.email.txt">text</a>
  60 or <a href="http://www.research.att.com/~smb/talks/key-agility.pdf">PDF
  61 slides</a> for a talk on the topic.</p>
  62
  63 <p>See also the NAI work mentioned in the next section.</p>
  64
  65 <h2><a name="perf.estimate">Estimating CPU overheads</a></h2>
  66
  67 <p>We can come up with a formula that roughly relates CPU speed to the rate
  68 of IPsec processing possible. It is far from exact, but should be usable as a
  69 first approximation.</p>
  70
  71 <p>An analysis of authentication overheads for high-speed networks, including
  72 some tests using FreeS/WAN, is on the <a
  73 href="http://www.pgp.com/research/nailabs/cryptographic/adaptive-cryptographic.asp">NAI
  74 Labs site</a>. In particular, see figure 3 in this <a
  75 href="http://download.nai.com/products/media/pgp/pdf/acsa_final_report.pdf">PDF
  76 document</a>. Their estimates of overheads, measured in Pentium II cycles per
  77 byte processed are:</p>
  78
  79 <table border="1" align="center">
  80   <tbody>
  81     <tr>
  82       <th></th>
  83       <th>IPsec</th>
  84       <th>authentication</th>
  85       <th>encryption</th>
  86       <th>cycles/byte</th>
  87     </tr>
  88     <tr>
  89       <td>Linux IP stack alone</td>
  90       <td>no</td>
  91       <td>no</td>
  92       <td>no</td>
  93       <td align="right">5</td>
  94     </tr>
  95     <tr>
  96       <td>IPsec without crypto</td>
  97       <td>yes</td>
  98       <td>no</td>
  99       <td>no</td>
 100       <td align="right">11</td>
 101     </tr>
 102     <tr>
 103       <td>IPsec, authentication only</td>
 104       <td>yes</td>
 105       <td>SHA-1</td>
 106       <td>no</td>
 107       <td align="right">24</td>
 108     </tr>
 109     <tr>
 110       <td>IPsec with encryption</td>
 111       <td>yes</td>
 112       <td>yes</td>
 113       <td>yes</td>
 114       <td align="right">not tested</td>
 115     </tr>
 116   </tbody>
 117 </table>
 118
 119 <p>Overheads for IPsec with encryption were not tested in the NAI work, but
 120 Antoon Bosselaers' <a
 121 href="http://www.esat.kuleuven.ac.be/~bosselae/fast.html">web page</a> gives
 122 cost for his optimised Triple DES implementation as 928 Pentium cycles per
 123 block, or 116 per byte. Adding that to the 24 above, we get 140 cycles per
 124 byte for IPsec with encryption.</p>
 125
 126 <p>At 140 cycles per byte, a 140 MHz machine can handle a megabyte -- 8
 127 megabits -- per second. Speeds for other machines will be proportional to
 128 this. To saturate a link  with capacity C megabits per second, you need a
 129 machine running at <var>C * 140/8 = C * 17.5</var> MHz.</p>
 130
 131 <p>However, that estimate is not precise. It ignores the differences
 132 between:</p>
 133 <ul>
 134   <li>NAI's test packets and real traffic</li>
 135   <li>NAI's Pentium II cycles, Bosselaers' Pentium cycles, and your machine's
 136     cycles</li>
 137   <li>different 3DES implementations</li>
 138   <li>SHA-1 and MD5</li>
 139 </ul>
 140
 141 <p>and does not account for some overheads you will almost certainly have:</p>
 142 <ul>
 143   <li>communication on the client-side interface</li>
 144   <li>switching between multiple tunnels -- re-keying, cache reloading and so
 145     on</li>
 146 </ul>
 147
 148 <p>so we suggest using <var>C * 25</var> to get an estimate with a bit of a
 149 built-in safety factor.</p>
 150
 151 <p>This covers only IP and IPsec processing. If you have other loads on your
 152 gateway -- for example if it is also working as a firewall -- then you will
 153 need to add your own safety factor atop that.</p>
 154
 155 <p>This estimate matches empirical data reasonably well. For example,
 156 Metheringham's tests, described <a href="#klips.bench">below</a>, show a 733
 157 topping out between 32 and 36 Mbit/second, pushing data as fast as it can
 158 down a 100 Mbit link. Our formula suggests you need at least an 800 to handle
 159 a fully loaded 32 Mbit link. The two results are consistent.</p>
 160
 161 <p>Some examples using this estimation method:</p>
 162
 163 <table border="1" align="center">
 164   <tbody>
 165     <tr>
 166       <th colspan="2">Interface</th>
 167       <th colspan="3">Machine speed in MHz</th>
 168     </tr>
 169     <tr>
 170       <th>Type</th>
 171       <th>Mbit per<br>
 172         second</th>
 173       <th>Estimate<br>
 174         Mbit*25</th>
 175       <th>Minimum IPSEC gateway</th>
 176       <th>Minimum with other load
 177
 178         <p>(e.g. firewall)</p>
 179       </th>
 180     </tr>
 181     <tr>
 182       <td>DSL</td>
 183       <td align="right">1</td>
 184       <td align="right">25 MHz</td>
 185       <td rowspan="2">whatever you have</td>
 186       <td rowspan="2">133, or better if you have it</td>
 187     </tr>
 188     <tr>
 189       <td>cable modem</td>
 190       <td align="right">3</td>
 191       <td align="right">75 MHz</td>
 192     </tr>
 193     <tr>
 194       <td><strong>any link, light load</strong></td>
 195       <td align="right"><strong>5</strong></td>
 196       <td align="right">125 MHz</td>
 197       <td>133</td>
 198       <td>200+, <strong>almost any surplus machine</strong></td>
 199     </tr>
 200     <tr>
 201       <td>Ethernet</td>
 202       <td align="right">10</td>
 203       <td align="right">250 MHz</td>
 204       <td>surplus 266 or 300</td>
 205       <td>500+</td>
 206     </tr>
 207     <tr>
 208       <td><strong>fast link, moderate load</strong></td>
 209       <td align="right"><strong>20</strong></td>
 210       <td align="right">500 MHz</td>
 211       <td>500</td>
 212       <td>800+, <strong>any current off-the-shelf PC</strong></td>
 213     </tr>
 214     <tr>
 215       <td>T3 or E3</td>
 216       <td align="right">45</td>
 217       <td align="right">1125 MHz</td>
 218       <td>1200</td>
 219       <td>1500+</td>
 220     </tr>
 221     <tr>
 222       <td>fast Ethernet</td>
 223       <td align="right">100</td>
 224       <td align="right">2500 MHz</td>
 225       <td rowspan="2" colspan="2" align="center">// not feasible with 3DES in
 226         software on current machines //</td>
 227     </tr>
 228     <tr>
 229       <td>OC3</td>
 230       <td align="right">155</td>
 231       <td align="right">3875 MHz</td>
 232     </tr>
 233   </tbody>
 234 </table>
 235
 236 <p>Such an estimate is far from exact, but should be usable as minimum
 237 requirement for planning. The key observations are:</p>
 238 <ul>
 239   <li>older <strong>surplus machines</strong> are fine for IPsec gateways at
 240     loads up to <strong>5 megabits per second</strong> or so</li>
 241   <li>a <strong>mid-range new machine</strong> can handle IPsec at rates up
 242     to <strong>20 megabits per second</strong> or more</li>
 243 </ul>
 244 <ul>
 245   <h3><a name="perf.more">Higher performance alternatives</a></h3>
 246
 247   <p><a href="glossary.html#AES">AES</a> is a new US government block cipher
 248   standard, designed to replace the obsolete <a
 249   href="glossary.html#DES">DES</a>. If FreeS/WAN using <a
 250   href="glossary.html#3DES">3DES</a> is not fast enough for your application,
 251   the AES <a href="web.html#patch">patch</a> may help.</p>
 252
 253   <p>To date (March 2002) we have had only one <a
 254   href="http://lists.freeswan.org/pipermail/users/2002-February/007771.html">mailing
 255   list report</a> of measurements with the patch applied. It indicates that,
 256   at least for the tested load on that user's network,  <strong>AES roughly
 257   doubles IPsec throughput</strong>. If further testing confirms this, it may
 258   prove possible to saturate an OC3 link in software on a high-end box.</p>
 259
 260   <p>Also, some work is being done toward support of <a
 261   href="compat.html#hardware">hardware IPsec acceleration</a> which might
 262   extend the range of requirements FreeS/WAN could meet.</p>
 263
 264   <h3>Other considerations</h3>
 265
 266   <p>CPU speed may be the main issue for IPsec performance, but of course it
 267   isn't the only one.</p>
 268
 269   <p>You need good ethernet cards or other network interface hardware to get
 270   the best performance. See this <a
 271   href="http://www.ethermanage.com/ethernet/ethernet.html">ethernet
 272   information</a> page and this <a href="http://www.scyld.com/diag">Linux
 273   network driver</a> page.</p>
 274
 275   <p>The current FreeS/WAN kernel code is largely single-threaded. It is SMP
 276   safe, and will run just fine on a multiprocessor machine (<a
 277   href="compat.html#multiprocessor">discussion</a>), but the load within the
 278   kernel is not shared effectively. This means that, for example to saturate
 279   a T3 -- which needs about a 1200 MHz machine -- you cannot expect something
 280   like a dual 800 to do the job. </p>
 281
 282   <p>On the other hand, SMP machines do tend to share loads well so --
 283   provided one CPU is fast enough for the IPsec work -- a multiprocessor
 284   machine may be ideal for a gateway with a mixed load.</p>
 285
 286   <h2><a name="biggate">Many tunnels from a single gateway</a></h2>
 287
 288   <p>FreeS/WAN allows a single gateway machine to build tunnels to many
 289   others. There may, however, be some problems for large numbers as indicated
 290   in this message from the mailing list:</p>
 291 </ul>
 292 <pre>Subject: Re: Maximum number of ipsec tunnels?
 293    Date: Tue, 18 Apr 2000
 294    From: "John S. Denker" &lt;jsd@research.att.com&gt;
 295
 296 Christopher Ferris wrote:
 297
 298 &gt;&gt; What are the maximum number ipsec tunnels FreeS/WAN can handle??
 299
 300 Henry Spencer wrote:
 301
 302 &gt;There is no particular limit.  Some of the setup procedures currently
 303 &gt;scale poorly to large numbers of connections, but there are (clumsy)
 304 &gt;workarounds for that now, and proper fixes are coming.
 305
 306 1) "Large" numbers means anything over 50 or so.  I routinely run boxes
 307 with about 200 tunnels.  Once you get more than 50 or so, you need to worry
 308 about several scalability issues:
 309
 310 a) You need to put a "-" sign in syslogd.conf, and rotate the logs daily
 311 not weekly.
 312
 313 b) Processor load per tunnel is small unless the tunnel is not up, in which
 314 case a new half-key gets generated every 90 seconds, which can add up if
 315 you've got a lot of down tunnels.
 316
 317 c) There's other bits of lore you need when running a large number of
 318 tunnels.  For instance, systematically keeping the .conf file free of
 319 conflicts requires tools that aren't shipped with the standard freeswan
 320 package.
 321
 322 d) The pluto startup behavior is quadratic.  With 200 tunnels, this eats up
 323 several minutes at every restart.   I'm told fixes are coming soon.
 324
 325 2) Other than item (1b), the CPU load depends mainly on the size of the
 326 pipe attached, not on the number of tunnels.
 327 </pre>
 328
 329 <p>It is worth noting that item (1b) applies only to repeated attempts to
 330 re-key a data connection (IPsec SA, Phase 2) over an established keying
 331 connection (ISAKMP SA, Phase 1). There are two ways to reduce this overhead
 332 using settings in <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>:</p>
 333 <ul>
 334   <li>set <var>keyingtries</var> to some small value to limit repetitions</li>
 335   <li>set <var>keylife</var> to a short time so that a failing data
 336     connection will be cleaned up when the keying connection is reset.</li>
 337 </ul>
 338
 339 <p>The overheads for establishing keying connections (ISAKMP SAs, Phase 1)
 340 are lower because for these Pluto does not perform expensive operations
 341 before receiving a reply from the peer.</p>
 342
 343 <p>A gateway that does a lot of rekeying -- many tunnels and/or low settings
 344 for tunnel lifetimes -- will also need a lot of <a
 345 href="glossary.html#random">random numbers</a> from the random(4) driver.</p>
 346
 347 <h2><a name="low-end">Low-end systems</a></h2>
 348
 349 <p><em>Even a 486 can handle a T1 line</em>, according to this mailing list
 350 message:</p>
 351 <pre>Subject: Re: linux-ipsec: IPSec Masquerade
 352    Date: Fri, 15 Jan 1999 11:13:22 -0500
 353    From: Michael Richardson
 354
 355 . . . A 486/66 has been clocked by Phil Karn to do
 356 10Mb/s encryption.. that uses all the CPU, so half that to get some CPU,
 357 and you have 5Mb/s. 1/3 that for 3DES and you get 1.6Mb/s....</pre>
 358
 359 <p>and a piece of mail from project technical lead Henry Spencer:</p>
 360 <pre>Oh yes, and a new timing point for Sandy's docs...  A P60 -- yes, a 60MHz
 361 Pentium, talk about antiques -- running a host-to-host tunnel to another
 362 machine shows an FTP throughput (that is, end-to-end results with a real
 363 protocol) of slightly over 5Mbit/s either way.  (The other machine is much
 364 faster, the network is 100Mbps, and the ether cards are good ones... so
 365 the P60 is pretty definitely the bottleneck.)</pre>
 366
 367 <p>From the above, and from general user experience as reported on the list,
 368 it seems clear that a cheap surplus machine -- a reasonable 486, a minimal
 369 Pentium box, a Sparc 5, ... -- can easily handle a home office or a small
 370 company connection using any of:</p>
 371 <ul>
 372   <li>ADSL service</li>
 373   <li>cable modem</li>
 374   <li>T1</li>
 375   <li>E1</li>
 376 </ul>
 377
 378 <p>If available, we suggest using a Pentium 133 or better. This should ensure
 379 that, even under maximum load, IPsec will use less than half the CPU cycles.
 380 You then have enough left for other things you may want on your gateway --
 381 firewalling, web caching, DNS and such.</p>
 382
 383 <h2><a name="klips.bench">Measuring KLIPS</a></h2>
 384
 385 <p>Here is some additional data from the mailing list.</p>
 386 <pre>Subject: FreeSWAN (specically KLIPS) performance measurements
 387    Date: Thu, 01 Feb 2001
 388    From: Nigel Metheringham &lt;Nigel.Metheringham@intechnology.co.uk&gt;
 389
 390 I've spent a happy morning attempting performance tests against KLIPS
 391 (this is due to me not being able to work out the CPU usage of KLIPS so
 392 resorting to the crude measurements of maximum throughput to give a
 393 baseline to work out loading of a box).
 394
 395 Measurements were done using a set of 4 boxes arranged in a line, each
 396 connected to the next by 100Mbit duplex ethernet.  The inner 2 had an
 397 ipsec tunnel between them (shared secret, but I was doing measurements
 398 when the tunnel was up and running - keying should not be an issue
 399 here).  The outer pair of boxes were traffic generators or traffic sink.
 400
 401 The crypt boxes are Compaq DL380s - Uniprocessor PIII/733 with 256K
 402 cache.  They have 128M main memory.  Nothing significant was running on
 403 the boxes other than freeswan.  The kernel was a 2.2.19pre7 patched
 404 with freeswan and ext3.
 405
 406 Without an ipsec tunnel in the chain (ie the 2 inner boxes just being
 407 100BaseT routers), throughput (measured with ttcp) was between 10644
 408 and 11320 KB/sec
 409
 410 With an ipsec tunnel in place, throughput was between 3268 and 3402
 411 KB/sec
 412
 413 These measurements are for data pushed across a TCP link, so the
 414 traffic on the wire between the 2 ipsec boxes would have been higher
 415 than this....
 416
 417 vmstat (run during some other tests, so not affecting those figures) on
 418 the encrypting box shows approx 50% system &amp; 50% idle CPU - which I
 419 don't believe at all.  Interactive feel of the box was significantly
 420 sluggish.
 421
 422 I also tried running the kernel profiler (see man readprofile) during
 423 test runs.
 424
 425 A box doing primarily decrypt work showed basically nothing happening -
 426 I assume interrupts were off.
 427 A box doing encrypt work showed the following:-
 428  Ticks Function                                   Load
 429  ~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ~~~~~~
 430    956 total                                      0.0010
 431    532 des_encrypt2                               0.1330
 432    110 MD5Transform                               0.0443
 433     97 kmalloc                                    0.1880
 434     39 des_encrypt3                               0.1336
 435     23 speedo_interrupt                           0.0298
 436     14 skb_copy_expand                            0.0250
 437     13 ipsec_tunnel_start_xmit                    0.0009
 438     13 Decode                                     0.1625
 439     11 handle_IRQ_event                           0.1019
 440     11 .des_ncbc_encrypt_end                      0.0229
 441     10 speedo_start_xmit                          0.0188
 442      9 satoa                                      0.0225
 443      8 kfree                                      0.0118
 444      8 ip_fragment                                0.0121
 445      7 ultoa                                      0.0365
 446      5 speedo_rx                                  0.0071
 447      5 .des_encrypt2_end                          5.0000
 448      4 _stext                                     0.0140
 449      4 ip_fw_check                                0.0035
 450      2 rj_match                                   0.0034
 451      2 ipfw_output_check                          0.0200
 452      2 inet_addr_type                             0.0156
 453      2 eth_copy_and_sum                           0.0139
 454      2 dev_get                                    0.0294
 455      2 addrtoa                                    0.0143
 456      1 speedo_tx_buffer_gc                        0.0024
 457      1 speedo_refill_rx_buf                       0.0022
 458      1 restore_all                                0.0667
 459      1 number                                     0.0020
 460      1 net_bh                                     0.0021
 461      1 neigh_connected_output                     0.0076
 462      1 MD5Final                                   0.0083
 463      1 kmem_cache_free                            0.0016
 464      1 kmem_cache_alloc                           0.0022
 465      1 __kfree_skb                                0.0060
 466      1 ipsec_rcv                                  0.0001
 467      1 ip_rcv                                     0.0014
 468      1 ip_options_fragment                        0.0071
 469      1 ip_local_deliver                           0.0023
 470      1 ipfw_forward_check                         0.0139
 471      1 ip_forward                                 0.0011
 472      1 eth_header                                 0.0040
 473      1 .des_encrypt3_end                          0.0833
 474      1 des_decrypt3                               0.0034
 475      1 csum_partial_copy_generic                  0.0045
 476      1 call_out_firewall                          0.0125
 477
 478 Hope this data is helpful to someone... however the lack of visibility
 479 into the decrypt side makes things less clear</pre>
 480
 481 <h2><a name="speed.compress">Speed with compression</a></h2>
 482
 483 <p>Another user reported some results for connections with and without IP
 484 compression:</p>
 485 <pre>Subject: [Users] Speed with compression
 486    Date: Fri, 29 Jun 2001
 487    From: John McMonagle &lt;johnm@advocap.org&gt;
 488
 489 Did a couple tests with compression using the new 1.91 freeswan.
 490
 491 Running between 2 sites with cable modems.  Both  using approximately
 492 130 mhz pentium.
 493
 494 Transferred files with ncftp.
 495
 496 Compressed file was a 6mb compressed  installation file.
 497 Non compressed was 18mb /var/lib/rpm/packages.rpm
 498
 499                             Compressed vpn          regular vpn
 500 Compress file                42.59 kBs               42.08 kBs
 501 regular file                110.84 kBs               41.66 kBs
 502
 503 Load  was about 0 either way.
 504 Ping times were very similar  a bit above 9 ms.
 505
 506 Compression looks attractive to me.</pre>
 507 Later in the same thread, project technical lead Henry Spencer added:
 508 <pre>&gt; is there a reason not to switch compression on?  I have large gateway boxes
 509 &gt; connecting 3 connections, one of them with a measly DS1 link...
 510
 511 Run some timing tests with and without, with data and loads representative
 512 of what you expect in production.  That's the definitive way to decide.
 513 If compression is a net loss, then obviously, leave it turned off.  If it
 514 doesn't make much difference, leave it off for simplicity and hence
 515 robustness.  If there's a substantial gain, by all means turn it on.
 516
 517 If both ends support compression and can successfully negotiate a
 518 compressed connection (trivially true if both are FreeS/WAN 1.91), then
 519 the crucial question is CPU cycles.
 520
 521 Compression has some overhead, so one question is whether *your* data
 522 compresses well enough to save you more CPU cycles (by reducing the volume
 523 of data going through CPU-intensive encryption/decryption) than it costs
 524 you.  Last time I ran such tests on data that was reasonably compressible
 525 but not deliberately contrived to be so, this generally was not true --
 526 compression cost extra CPU cycles -- so compression was worthwhile only if
 527 the link, not the CPU, was the bottleneck.  However, that was before the
 528 slow-compression bug was fixed.  I haven't had a chance to re-run those
 529 tests yet, but it sounds like I'd probably see a different result. </pre>
 530 The bug he refers to was a problem with the compression libraries that had us
 531 using C code, rather than assembler, for compression. It was fixed before
 532 1.91.
 533
 534 <h2><a name="methods">Methods of measuring</a></h2>
 535
 536 <p>If you want to measure the loads FreeS/WAN puts on a system, note that
 537 tools such as top or measurements such as load average are more-or-less
 538 useless for this. They are not designed to measure something that does most
 539 of its work inside the kernel.</p>
 540
 541 <p>Here is a message from FreeS/WAN kernel programmer Richard Guy Briggs on
 542 this:</p>
 543 <pre>&gt; I have a batch of boxes doing Freeswan stuff.
 544 &gt; I want to measure the CPU loading of the Freeswan tunnels, but am
 545 &gt; having trouble seeing how I get some figures out...
 546 &gt;
 547 &gt;  - Keying etc is in userspace so will show up on the per-process
 548 &gt;    and load average etc (ie pluto's load)
 549
 550 Correct.
 551
 552 &gt;  - KLIPS is in the kernel space, and does not show up in load average
 553 &gt;    I think also that the KLIPS per-packet processing stuff is running
 554 &gt;    as part of an interrupt handler so it does not show up in the
 555 &gt;    /proc/stat system_cpu or even idle_cpu figures
 556
 557 It is not running in interrupt handler.  It is in the bottom half.
 558 This is somewhere between user context (careful, this is not
 559 userspace!) and hardware interrupt context.
 560
 561 &gt; Is this correct, and is there any means of instrumenting how much the
 562 &gt; cpu is being loaded - I don't like the idea of a system running out of
 563 &gt; steam whilst still showing 100% idle CPU :-)
 564
 565 vmstat seems to do a fairly good job, but use a running tally to get a
 566 good idea.  A one-off call to vmstat gives different numbers than a
 567 running stat.  To do this, put an interval on your vmstat command
 568 line.</pre>
 569 and another suggestion from the same thread:
 570 <pre>Subject: Re: Measuring the CPU usage of Freeswan
 571    Date: Mon, 29 Jan 2001
 572    From: Patrick Michael Kane &lt;modus@pr.es.to&gt;
 573
 574 The only truly accurate way to accurately track FreeSWAN CPU usage is to use
 575 a CPU soaker. You run it on an unloaded system as a benchmark, then start up
 576 FreeSWAN and take the difference to determine how much FreeSWAN is eating.
 577 I believe someone has done this in the past, so you may find something in
 578 the FreeSWAN archives.  If not, someone recently posted a URL to a CPU
 579 soaker benchmark tool on linux-kernel.</pre>
 580 </body>
 581 </html>