I don't really trust the vmstat system time numbers. Based on some
suggestions I received, I ran some CPU intensive benchmarks during
different traffic loads, and determined how much system time was being
used by comparing the real and user times. The results seem to show that
if I want to do 50Mbps full-duplex on 2 ports (200M aggregate) that the
standard Linux 2.2.20 routing code won't cut it.
Unloaded Duron 1G
root@TO-VS ~# time bzip2 /tmp/words
real 0m0.414s
user 0m0.400s
sys 0m0.010s
750Mhz Duron, ~20Mbps traffic, 8K int/sec
vmstat reported CPU idle: 98% (2% system)
root@tor-router ~# time bzip2 /tmp/words
real 0m0.628s
user 0m0.380s
sys 0m0.160s
CPU load ~= 40%
root@tor-router ~# time bzip2 /tmp/words
real 0m0.552s
user 0m0.460s
sys 0m0.090s
CPU load ~=16%
750Mhz Duron, ~60Mbps traffic, 20K int/sec
vmstat reported CPU idle: 95% (5% system)
root@tor-router ~# time bzip2 /tmp/words
real 0m1.071s
user 0m0.370s
sys 0m0.690s
CPU load ~= 65%
root@tor-router ~# time bzip2 /tmp/words
real 0m1.041s
user 0m0.440s
sys 0m0.600s
CPU load ~= 58%
[snip bogus benchmark]
Why are you benchmarking network troughput by bzip2'ing a file in
/tmp? It makes no sense.
Greetz, Peter
interrupts are taking up CPU time, and vmstat is not accurately reporting
it. I need *something* compute intensive to infer load by seeing how many
cycles are left over.
-Ralph
You might want to try Zebra and some actual traffic, rather than an extremely CPU intensive compression program. Compressing a file, even in swap, is by no means a good way to judge the aggregate throughput and routing capabilities of a system, regardless of the OS or platform. (That is unless you were planning on bzip2'ing all of your packet flows.)
ralph@istop.com wrote:
I'm suspecting that he's trying to indirectly measure the kernel CPU usage.
Most kernels don't give you the time spent in kernel mode (or bill
it incorrectly to a process - I seem to remember some handwaving in either
the Keifler&McKusic or Bach books about how interrupt time is charged against
the current process, but it usually evens out in the end). So what you end
up doing is running a cycle-sucking CPU-bound process, and seeing how much
progress it makes - if in 60 seconds, the cycle sucker gets 45, then your
kernel is getting the other 25% (or so the theory goes).
It's not perfect, but it works as a back-of-envelope test and is probably
accurate to within 5-10%...