[netperf-talk] problem connecting to netserver

[Rick Jones]

Bahadir Balban wrote:
> On 3/7/06, Rick Jones <rick.jones2 at hp.com> wrote:
> 
>>Bahadir Balban wrote:
>>
>>>netperf -d -v -h 10.1.202.155 -t TCP_STREAM -l 20 -- -m 64
>>>Host name: localhost
>>>Are you sure there is a netserver running on localhost at port 12865?
>>
>>Notice how it asked if there was a netserver running on localhost?  That
>>implies that it didn't know you wanted the control connection to go to
>>10.1.202.155.
>>
>>Anyway, my first suggestion would be to try "-H" rather than "-h" and
>>see what you get.
>>
>>happy benchmarking,
>>
>>rick jones
> 
> 
> Hi,
> 
> I tried the same command with -H, and I got two responses, one was
> exactly the same as above, and one was:
> regression check TCP throughput with ascending packet sizes
> recv_response: partial response received: 0 bytes

"Regression check..." is a message completely unfamiliar to me.  Is that 
something from a script of yours?

The second part suggests that the remote netserver died for some reason. 
  Starting/launching the netserver with -d to increase debugging output 
might be a good idea.  Might look for a core file from netserver.

> For the first response, I don't understand why netperf assumes it is a
> localhost, where the remote ip is clearly given, (and its on the same
> network where netperf is ran)

Netperf will take the parameter provided in the -H option and pass it to 
getaddrinfo.  It will take what getaddrinfo returns as the hostname and 
display it.  Is there an entry for 10.1.202.155 in your local /etc/hosts 
file?

> If I try the same test on another platform, with same kernel and
> filesystem, and same ethernet device, it works. The two platforms are
> different, but the biggest difference is the working platform runs at
> about 40Mhz and the failing one is about 20Mhz.

I cannot think of any race conditions in netperf that would care about 
the speed of the systems.  It's history goes back to a time when 40 or 
even 20 MHz was not necessarily all that slow and was working fine then :)

> Also, even though slow, I know that the failing one has successful
> network transfers, because I am booting linux on it using an nfs
> filesystem as the root filesystem.
> 
> Any debugging ideas?

The debug option -d, system call tracing, looking for core files, 
checking the /etc/hosts files

happy benchmarking,

rick jones

> 
> Thanks,
> Bahadir