As asked in LKML thread, please post the exact netperf command used to
start the client/server, whether or not you're using irqbalanced (aka
irqbalance) and what cat /proc/interrupts looks like (you ARE using MSI,
right?)
In particular, it would be good to know if you are doing two concurrent
streams, or if you are using the "burst mode" TCP_RR with large
request/response sizes method which then is only using one connection.
I've recently discovered that particularly with the most recent kernels
if you specify any socket options (-- -SX -sY) to netperf it does worse
than if it just lets the kernel auto-tune.
That is the bit where explicit setsockopts are capped by core [rw]mem
sysctls but the autotuning is not correct?
rick jones
BTW, a bit of netperf news - the "omni" (two routines to measure it all)
tests seem to be more or less working now in top of trunk netperf. It
of course still needs work/polish, but if folks would like to play with
them, I'd love the feedback. Output is a bit different from classic
netperf, and includes an option to emit the results as csv
(test-specific -o presently) rather than "human readable" (test-specific
-O). You get the omni stuff via ./configure --enable-omni and use
"omni" as the test name. No docs yet, for options and their effects,
you need to look at scan_omni_args in src/nettest_omni.c
One other addition in the omni tests is retreiving not just the initial
SO_*BUF sizes, but also the final SO_*BUF sizes so one can see where
autotuning took things just based on netperf output.
If the general concensus is that the overhead of the omni stuff isn't
too dear, (there are more conditionals in the mainline than with classic
netperf) I will convert the classic netperf tests to use the omni code.
BTW, don't have a heart attack when you see the quantity of current csv
output - I do plan on being able to let the user specify what values
should be included :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
