Thread (26 messages) 26 messages, 10 authors, 2005-04-08

Re: [RFC] TCP congestion schedulers

From: Stephen Hemminger <hidden>
Date: 2005-03-28 23:51:17

On 22 Mar 2005 08:41:22 +0100
Andi Kleen [off-list ref] wrote:
On Mon, Mar 21, 2005 at 04:25:56PM -0500, John Heffner wrote:
quoted
On Sat, 19 Mar 2005, Andi Kleen wrote:
quoted
Stephen Hemminger [off-list ref] writes:
quoted
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.
Is there a canonical benchmark?
For the LSM case we saw the problem with running netperf over loopback. 
It added one or two hooks per packet, but it already made a noticeable
difference on IA64 boxes.

On other systems it is unnoticeable.
quoted
Would you really expect a single extra indirect call per ack to have a
significant performance impact?  This is surprising to me.  Where does the
cost come from?  Replacing instruction cache lines?
I was never quite clear. Some instruction stalls in the CPUs. 
One not very good theory was that McKinley really likes
to have its jump registers loaded early for indirect calls, and gcc
doesn't even attempt this.

-Andi
Running on 2 Cpu Opteron using netperf loopback mode shows that the change is
very small when averaged over 10 runs. Overall there is 
a .28% decrease in CPU usage and a .96% loss in throughput.  But both those
values are less than twice standard deviation which was .4% for the CPU measurements
and .8% for the performance measurements.  I can't see it as a worth
bothering unless there is some big money benchmark on the line, in which case
it would make more sense to look at other optimizations of the loopback
path.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help