but clearly I should be using netperf to get more accurate cpu numbers
and a more convincing aggregate table :-)
Well, I'll not stop you :)
It is a bit rough/messy as a writeup, but here is what I've seen wrt the
latency vs throughput tradeoffs:
ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt
from a quick read it looks like just the case with 32kB messages,
multiple simultaneous clients, and driver set to unlimited ITR sees
reduced throughput. is that right?
if so, then I'm not surprised.
There should be three basic measures there - one is the single-instance
request-response test. The idea is to see minimum latency. That test
likes to see the interrupt throttle rate made very high, or disabled
completely.
The aggregate TCP_RR's and the TCP_STREAM tests are there to show what
effect that has on the ability to do aggregate request/response and a
bulk transfer.
but overall I'm actually more worried about a mix of small and large
messages than multiple clients.
a large/small mix might well occur in 'the real world' and it'll be 2s
until the watchdog routine can adapt the ITR. potentially that 2s will
be at 200k ITR which is too high for large messages, and up to 2s of
cpu will be burnt needlessly.
can netperf (or some other tool) mix up big and small message sizes
like 'the real world' perhaps does?
that might help me find a good frequency at which to try to adapt the
ITR... (eg. 1, 10, 100 or 1000 times a second)
There is the "vst" (variable size test IIRC) in netperf4:
http://www.netperf.org/svn/netperf4/branches/glib_migration
The docs for netperf4 are presently pathetic. Feel free to email me for
bootstrapping information. Basically, you'll need pkg-config, libxml2
and glib-2.0 on the system.
cheers,
robin
-
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
