Fw: [netperf-talk] TCP_MAERTS "len was -1" issue

[Rick Jones]

Eric Hultin wrote:
> 
> This must have gotten lost in your upgrades over thanksgiving, is there 
> any way you would be able to respond to the attached e-mail? Thank you 
> for any info you can provide.

I suspect that theprolonged shutdown led to messages being dropped - if 
not to others on netperf-talk, almost certainly to me... sigh.

> We have been running TCP_STREAM tests with no problems with the 
> following command line on Linux:
> 
> ../netperf -H 10.18.212.230 -l 5 -t TCP_STREAM -f k  -- -s 64K -S 64K -m 
> 64K -M 64K
> 
> Normally, we telnet on to the two PCs and perform a simultaneous test by 
> running netperf on both units simultaneously. Due to some issues in our 
> lab we are starting to use the TCP_MAERTS test to gather performance 
> numbers so that we can run both the upstream and downstream tests from a 
> single computer. However we are noticing the following problem:
> 
> ../netperf -H 10.18.212.230 -l 5 -t TCP_MAERTS -f k  -- -s 64K -S 64K -m 
> 64K -M 64K
> TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.18.212.230 
> (10.18.212.230) port 0 AF_INET
> send_tcp_maerts: data recv error: Interrupted system call
> len was -1
> 
> When we run without the buffer settings it seems to work OK:
> 
> ../netperf -H 10.18.212.230 -l 5 -t TCP_MAERTS -f k  --
> TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.18.212.230 
> (10.18.212.230) port 0 AF_INET
> Recv   Send    Send
> Socket Socket  Message  Elapsed
> Size   Size    Size     Time     Throughput
> bytes  bytes   bytes    secs.    10^3bits/sec
> 
> 87380  16384  16384    7.70      119.11
> 
> Also, the TCP_STREAM test seems to work correctly on the other machine 
> when we try emulating what the TCP_MAERTS test should be doing. We are 
> running this with a Cable Modem which is rate limited to 128K/64K DS/US. 
>  This behavior was seen on netperf 2.4.0, 2.4.2, and a copy built from 
> the latest subversion repository. This is running on  Fedora Core 2 with 
> the 2.6.10 kernel. Thanks in advance for any advice you can provide.

Hmm, normally, (these days at least) I leave-off the -M option for both 
TCP_STREAM and TCP_MAERTS on the ass-u-me-ption that the receiver will 
take-in as much data as possible in one call.  I wouldn't think that 
would matter here though.

I think the next step is seeing just what signal netperf is taking and 
when - so a verbose strace would be my next suggestion.

happy benchmarking,

rick jones

BTW, since you are measuring bidirectional, there is a second way to do 
it which is "different" - if you ./configure --enable-burst you can use 
the TCP_RR test and put multiple requests into the connection at one 
time to keep the thing busy in both directions at once:

netperf -H <host> -t TCP_RR -- -s 256K -S 256K -r 32K -b 6

is one I use often - has has many as 7 requests outstanding on the 
connection at one time, which often is enough to saturate things.  The 
only downside is having to convert the trans/s into mbit/s by hand :)

Differences from a pair of TCP_STREAMS or a TCP_STREAM and a TCP_MAERTS:

*) One connection rather than two means less opportunity for multiple 
CPUs to take part

*) May not expose inequities in transmit vs receive processing by a 
NIC/driver since the application is forcing equality on its own

*) Easier to run the one instance than two - fewer synchronization issues