When parsing the -P option in scan_socket_args() of src/nettest_bsd.c,
netperf is using break_args() from src/netsh.c which indeed if the
command line says -P 12345 will set both the local and remote port
numbers to 12345. If instead you were to say -P 12345, it will use
12345 only for the
On Tue, 2008-01-22 at 10:36 -0800, Rick Jones wrote:
When parsing the -P option in scan_socket_args() of src/nettest_bsd.c,
netperf is using break_args() from src/netsh.c which indeed if the
command line says -P 12345 will set both the local and remote port
numbers to 12345. If instead you
On Wed, 2008-01-23 at 08:42 +0800, Zhang, Yanmin wrote:
On Tue, 2008-01-22 at 10:36 -0800, Rick Jones wrote:
When parsing the -P option in scan_socket_args() of src/nettest_bsd.c,
netperf is using break_args() from src/netsh.c which indeed if the
command line says -P 12345 will set both
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
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
From: Zhang, Yanmin [EMAIL PROTECTED]
Date: Tue, 22 Jan 2008 14:07:19 +0800
I am wondering if UDP stack in kernel has a bug.
If one server binds to INADDR_ANY with port N, then any other socket
can be bound to a specific IP address with port N. When packets
come in destined for port N, the
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
On Mon, 2008-01-21 at 22:22 -0800, David Miller wrote:
From: Zhang, Yanmin [EMAIL PROTECTED]
Date: Tue, 22 Jan 2008 14:07:19 +0800
I am wondering if UDP stack in kernel has a bug.
If one server binds to INADDR_ANY with port N, then any other socket
can be bound to a specific IP address
On Tue, 2008-01-22 at 07:27 +0100, Eric Dumazet wrote:
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.
Zhang, Yanmin a écrit :
On Mon, 2008-01-21 at 22:22 -0800, David Miller wrote:
From: Zhang, Yanmin [EMAIL PROTECTED]
Date: Tue, 22 Jan 2008 14:07:19 +0800
I am wondering if UDP stack in kernel has a bug.
If one server binds to INADDR_ANY with port N, then any other socket
can be bound to a
From: Zhang, Yanmin [EMAIL PROTECTED]
Date: Tue, 22 Jan 2008 14:52:32 +0800
I double-checked it and they are queued to socket A. If I define a
different local port for netperf, packets will be queued to socket
B.
This does not prove the kernel is buggy.
If netperf is binding to devices, that
On Mon, 2008-01-14 at 21:53 +1100, Herbert Xu wrote:
On Mon, Jan 14, 2008 at 08:44:40AM +, Ilpo J�rvinen wrote:
I tried to use bisect to locate the bad patch between 2.6.22 and
2.6.23-rc1,
but the bisected kernel wasn't stable and went crazy.
TCP work between that is very
On Wed, 2008-01-16 at 08:34 +0800, Zhang, Yanmin wrote:
On Mon, 2008-01-14 at 21:53 +1100, Herbert Xu wrote:
On Mon, Jan 14, 2008 at 08:44:40AM +, Ilpo Jrvinen wrote:
I tried to use bisect to locate the bad patch between 2.6.22 and
2.6.23-rc1,
but the bisected kernel
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
The regression is:
1)stoakley with 2 qual-core processors: 11%;
2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
I have new update on this issue and also cc to netdev maillist.
Thank
On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
regression is between 16%~11%.
I tried to use bisect to locate the
On Mon, 2008-01-14 at 11:21 +0200, Ilpo J�rvinen wrote:
On Mon, 14 Jan 2008, Ilpo J�rvinen wrote:
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
On Mon, Jan 14, 2008 at 08:44:40AM +, Ilpo Järvinen wrote:
I tried to use bisect to locate the bad patch between 2.6.22 and
2.6.23-rc1,
but the bisected kernel wasn't stable and went crazy.
TCP work between that is very much non-existing.
Make sure you haven't switched between
*) 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
On Fri, 2008-01-11 at 09:56 -0800, Rick Jones wrote:
The test command is:
#sudo taskset -c 7 ./netserver
#sudo taskset -c 0 ./netperf -t TCP_RR -l 60 -H 127.0.0.1 -i 50,3 -I 99,5
-- -r 1,1
A couple of comments/questions on the command lines:
Thanks for your kind comments.
*)
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
The regression is:
1)stoakley with 2 qual-core processors: 11%;
2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
I have new update on this issue and also cc to netdev maillist.
Thank David Miller for pointing me the netdev maillist.
The test command is:
#sudo taskset -c 7 ./netserver
#sudo taskset -c 0 ./netperf -t TCP_RR -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 -- -r
1,1
A couple of comments/questions on the command lines:
*) netperf/netserver support CPU affinity within themselves with the
global -T option to netperf. Is
21 matches
Mail list logo
