On Sat, 19 Mar 2005, Andi Kleen wrote:
> Stephen Hemminger <shemminger@xxxxxxxx> writes:
> > Since developers want to experiment with different congestion
> > control mechanisms, and the kernel is getting bloated with overlapping
> > data structure and code for multiple algorithms; here is a patch to
> > split out the Reno, Vegas, Westwood, BIC congestion control stuff
> > into an infrastructure similar to the I/O schedulers.
> Did you do any benchmarks to check that wont slow it down?
> I would recommend to try it on a IA64 machine if possible. In the
> past we found that adding indirect function calls on IA64 to networking
> caused measurable slowdowns in macrobenchmarks.
> In that case it was LSM callbacks, but your code looks like it will
> add even more.
For the record, here are some benchmarks from an ia64 over GigE. I
set the MTU to 564 so it actually stressed the CPU. Numbers are
throughput (10^6 bits/sec).
Command line used: netperf -H 192.168.1.3 -l -1000000000 -c -C -v 2.
The sender was a 1-CPU 900 MHz Itanium2. The receiver was a 1-CPU 2.4 GHz
Pentium 4. The sender reported over 99% utilization; the receiver
reported about 50%. The NICs were both fiber SysKonnect 9843's connected
back to back.
Normal reno Modular reno
average 392.76 393.49
stdev 0.79 0.44