Re: CPU load due to IP networking
From: Craig Partridge (craigp_at_std.com)
Date: Thu, 23 Jun 2005 11:54:12 +0000 (UTC)
"jbl" <email@example.com> writes:
>I've been looking for some information on the web, in white papers and
>even on Usenet, but if it exists I can't seem to put together a search
>that finds it. I'm asking here if anyone knows of something along
>these lines and can point me to it.
There was a lot of ink spilled on this topic in the 1990s -- a bunch of
good papers. Unfortunately, the results aren't as clear cut as you'd
It also gets much tougher if you try to make a linux box act like
a router (which it sounds as if you're interested in doing).
But let's be simple minded and say you're running as a host. No OSPF
or BGP -- just TCP or UDP in and out to a default route.
Then assuming a reasonably good TCP implementation and a poor quality buffering
system, you'll expend about 3 or 4 instructions (or, 3 or 4 memory accesses,
whichever is slower) per word of data sent via TCP, NOT INCLUDING DEVICE
DRIVER/INTERRUPT COSTS. Note that a high quality TCP with a good
buffering system/zero copy memory will be under half that cost, while
a poor TCP can easily push it higher.
Device driver and interrupt costs vary so widely based on your interface
hardware that it is hard to estimate. (In the old days, a factor of two
difference was common using different cards in the same box with the same
software -- haven't done tests on interfaces in ages, so can't say today).
UDP costs are more variable and can be higher or lower than TCP depending
on buffering design. Most UDP implementations are not optimized very
In many ways you're probably best off running a test of TCP tests
where the application writes at different sizes and plotting size vs.
CPU costs. Make sure to have other applications running (so TCP has
at least some competition for memory) and have several other TCP
connections running with at least low levels of traffic (so your
TCB cache gets some work).