[netperf-talk] Re: no receiving speed for UDP_STREAM

[Rick Jones]

Ming Liu wrote:
> Dear all, I am using netperf to measure the performance of my 
> network(ml403 board with temac enet connected to a pc directly). when I 
> send data from pc to board using UDP_STREAM, the data rate for receiving 
> is zero.
> # netperf -H 192.168.0.5 -c -C -t UDP_STREAM -- -s 40960 -S 40960 -m 
> 1024 UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET 
> to 192.168.0.5 (192.168.0.5) port 0 AF_INET Socket  Message  
> Elapsed      Messages                   CPU      Service Size    
> Size     Time         Okay Errors   Throughput   Util     Demand bytes   
> bytes    secs            #      #   10^6bits/sec % SU     us/KB
> 81920    1024   10.00     1143076      0      936.0     -123.60   
> -3091392.750 81920           10.00           8               0.0     
> -1.00    -12505.536
> 
>> From the above statistics, we can see that the sending speed is 936.0 

And that 8 UDP datagrams made it to the remote.  It also looks like the
CPU utilization report is rather fubar.

> bits/s. However the receiving speed of the board is 0.0. what's the 
> problem? When I transfer data from board to PC there is no such a 
> problem. Its result shows like,
> #./netperf -H 192.168.0.3 -c -C -t UDP_STREAM UDP UNIDIRECTIONAL SEND 
> TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.3 (192.168.0.3) 
> port 0 AF_INET Socket  Message  Elapsed      Messages                   
> CPU      Service Size    Size     Time         Okay Errors   
> Throughput   Util     Demand bytes   bytes    secs            #      #   
> 10^6bits/sec % US     us/KB
> 104448   65507   10.00        3824      0      200.4     -1.00    0.000 
> 137216           10.00        3824             200.4     -235.53   -192.574
> 
> 
> Can anyone tell me how to solve this problem? Thanks for your help.

UDP has no flow-control.  Netperf UDP_STREAM does not try to add any
sort of flow control.  The PC was able to send data so fast to the board
that apart from those 8 datagrams it received, it was so overwhelmed by
the inbound data rate that it spent all its time just receiving
datagrams and discarding them.  Probably when trying to put them into
the socket on the receiving side.

When you switched from a fast sender/slow receiver to slow sender/fast
receiver, the receiver was able to keep-up with the data being sent.
Notice how your board reports sending at only 200 Mbit/s rather than the
9XX Mbit/s of the PC.

If you reconfigure netperf to --enable-intervals you will be able to
"pace" the sends of netperf with the added -w and -b options.  With this
you can slow-down the sender and match its rate with what the receiver
can handle.

happy benchmarking,

rick jones
> BR Ming
> 
> _________________________________________________________________
> ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com