[netperf-talk] Question on UDP test

[Jay Kim]

Thanks so much, Andrew.
Changing message size with '-m' option works for me.

However, when I used your example with '-s' and '-S' option, then, I received the following error messages;

$ netperf -H demeter -tUDP_STREAM -- -m 1472 -S 2097152 
WARNING! getaddrinfo returned a protocol other than the
requested protocol.  Please contact your vendor for
a fix to this bug in getaddrinfo()
UDP UNIDIRECTIONAL SEND TEST from ::ffff:0.0.0.0 (0.0.0.0) port 0 AF_INET to demeter (10.89.1.122) port 0 AF_INET : interval
recv_response: partial response received: 0 bytes

$ netperf -H demeter -tUDP_STREAM -- -m 1472 -s 2097152
WARNING! getaddrinfo returned a protocol other than the
requested protocol.  Please contact your vendor for
a fix to this bug in getaddrinfo()
UDP UNIDIRECTIONAL SEND TEST from ::ffff:0.0.0.0 (0.0.0.0) port 0 AF_INET to demeter (10.89.1.122) port 0 AF_INET : interval
netperf: set_sock_buffer: SO_SNDBUF option: errno 132

Do I have to use the options with super user privileges?

- jay



----- Original Message ----- 
From: "Andrew Gallatin" <gallatin at cs.duke.edu>
To: "Jay Kim" <jay.m.kim at samsung.com>
Cc: <netperf-talk at netperf.org>
Sent: Friday, January 04, 2008 11:00 PM
Subject: Re: [netperf-talk] Question on UDP test


> 
> Jay Kim writes:
> > 
> > Hi, I have a simple question on UDP_STREAM test result.
> > I've got the following result, but I wonder why the throughput is measured only at client side.
> > 
> > UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.2.50.1 (10.2.50.1) port 0 AF_INET
> > Socket  Message  Elapsed      Messages                
> > Size    Size     Time         Okay Errors   Throughput
> > bytes   bytes    secs            #      #   10^6bits/sec
> > 
> > 2097152   65507   10.00         960      0      50.29
> > 2097152           10.00           0              0.00
> 
> It is measured at both the client and server side.  Your results
> show that the server received exactly 0 datagrams.
> 
> The message size you are using (65507), when combined with with a 1500
> byte MTU will lead to each datagram being fragemented into roughly 45
> IP packets.  If just one of those is dropped, the reassembly will
> fail.  The first thing I'd do is check netstat -s to look for problems
> like this.
> 
> You may have better results using a datagram size (like 1472)
> which will not require IP fragmentation:
> 
> netperf -H10.2.50.1 -tUDP_STREAM -- -m 1472 -S 2097152 -s 2097152
> 
> Drew