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%
On Tue, May 21, 2002 at 06:34:47PM -0400, Ralph Doncaster wrote:
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. [snip bogus benchmark]
Why are you benchmarking network troughput by bzip2'ing a file in /tmp? It makes no sense. Greetz, Peter -- huk ~ kek
On Tue, May 21, 2002 at 06:34:47PM -0400, Ralph Doncaster wrote:
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. [snip bogus benchmark]
Why are you benchmarking network troughput by bzip2'ing a file in /tmp? It makes no sense.
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:
On Tue, May 21, 2002 at 06:34:47PM -0400, Ralph Doncaster wrote:
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.
[snip bogus benchmark]
Why are you benchmarking network troughput by bzip2'ing a file in /tmp? It makes no sense.
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
On Wed, 22 May 2002 09:45:46 +0200, Peter van Dijk <peter@dataloss.nl> said:
Why are you benchmarking network troughput by bzip2'ing a file in /tmp? It makes no sense.
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%... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
participants (4)
-
Anthony D Cennami -
Peter van Dijk -
Ralph Doncaster -
Valdis.Kletnieks＠vt.edu