i-perf report

Hi,

I am using i-perf to pump UDP traffic to our experimental network .
I am transmitting data at a speed of 7mbs for 300secs. The link speed
is 10mbs. The command I used is :

i-perf -u -c <i-perf server ip > -b 7m -t 300

The i-perf server is started at another end (different network)
using
i-perf -s -u

Now when the data transmission is finished , the server sends the
bandwidth statistics to the client. But when the statistics reaches
the client , the statistics become doubled .

Can anybody can put light on this issue ?

With Thanks

(E-Mail Removed) wrote:
> I am using i-perf to pump UDP traffic to our experimental network .
> I am transmitting data at a speed of 7mbs for 300secs. The link
> speed is 10mbs. The command I used is :

> i-perf -u -c <i-perf server ip > -b 7m -t 300

> The i-perf server is started at another end (different network)
> using

> i-perf -s -u

> Now when the data transmission is finished , the server sends the
> bandwidth statistics to the client. But when the statistics reaches
> the client , the statistics become doubled .

The bandwidth stats, or just things like the socket buffer sizes?

As a sanity check, you could try a different tool. I of course would
suggest netperf

The bandwidth contraining is a little less direct than iperf, but
basically:

../configure --enable-intervals

the usual make stuff (don't forget to put the bits on both systems,
although the "netserver" side doesn't need --enable-intervals)

then something like

netserver # on the system to act as netserver - it will daemonize

netperf -T UDP_STREAM -H <netserver> -w <time> -b <burstsize> -- -m <size>

where you pick the -w and -b settings for time an burst size to hit
the bandwidth you want with the message size you use. If the
granularity of the interval timer on your system is too coarse, you
can add --enable-spin to the configure, and instead of using the
interval timer, netperf will sit and spin until it is time to send
traffic again. That of course will play havoc with CPU utilization on
the system running netperf.

You may want to play with some socket sizes set via test-specific
options. More about installing and running netperf can be seen at:

http://www.netperf.org/svn/netperf2/...c/netperf.html for top-of-trunk

or

http://www.netperf.org/svn/netperf2/...c/netperf.html

for the current released version.

> Can anybody can put light on this issue ?

In theory, since IP datagrams can be lost, corrupted, or duplicated, UDP datagrams carried in IP datagrams can also be duplicated. In practice that _should_ virtually never happen. If the netperf UDP

--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...