Zhang, Yanmin a écrit :
On Tue, 2008-01-22 at 13:24 +0800, Zhang, Yanmin wrote:
On Mon, 2008-01-14 at 09:46 -0800, Rick Jones wrote:
*) netperf/netserver support CPU affinity within themselves with the
global -T option to netperf. Is the result with taskset much different?
The equivalent to the above would be to run netperf with:
./netperf -T 0,7 ..
I checked the source codes and didn't find this option.
I use netperf V2.3 (I found the number in the makefile).
Indeed, that version pre-dates the -T option. If you weren't already
chasing a regression I'd suggest an upgrade to 2.4.mumble. Once you are
at a point where changing another variable won't muddle things you may
want to consider upgrading.
happy benchmarking,
Rick,
I found my UDP_RR testing is just loop in netperf instead of ping-pang between
netserver and netperf. Is it correct? TCP_RR is ok.
#./netserver
#./netperf -t UDP_RR -l 60 -H 127.0.0.1 -i 30,3 -I 99,5 -- -P 12384 -r 1,1
I digged into netperf and netserver.
netperf binds ip 0 and port 12384 to its own socket. netserver binds ip
127.0.0.1 and port 12384 to its own socket. Then, netperf calls connect to
setup server
127.0.0.1 and port 12384. Then, netperf starts sends UDP packets, but all
packets netperf
sends are just received by netperf itself. netserver doesn't receive any packet.
I think netperf binding should fail, or netperf shouldn't get the packet it
sends out, because
netserver already binds port 12384.
I am wondering if UDP stack in kernel has a bug.
If :
- socket A is bound to 0.0.0.0:12384 and
- socket B is bound to 127.0.0.1:12384
Then packets sent to 127.0.0.1:12384 should be queued for socket B
If they are queued to socket A as you believe it is currently done, then yes
there is a bug in kernel.
TCP_RR testing hasn't such issue.
-yanmin
--
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
--
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
