Re: bandwidth option ( -b ) in udp
Ok I understand your needs, but unfortunately knowledge of IP headers, UDP
headers, checksum etc is not trivial. You could assume that there are no
IP options and that you are on ethernet and figure out what all the
headers would total, but what about ATM, HIPPI, FDDI, etc. There is no way
to really before hand compute the amount of headers a piece of information
will get covered with. You mention that an approximation would work, but
even with that for your needs it may still send over the 100Mb/s and you
could experience undue packet loss so it would be no better than now. As
such we leave this to the users to determine. A simple formula for it
would be <Amount_to_transfer>*<PacketSize>/(<PacketSize> + <HeaderSize>).
Sorry for not having a better solution.
Kevin
On Thu, 23 Jan 2003 Steve.Brenne --at-- radisys.com wrote:
>
> Kevin,
> We are using Iperf to test Ethernet switch based products in
> manufacturing. We are basically sending packets through a switch between 2
> PC's. We were experiencing packet loss when sending traffic into a GBE
> port and out a FE port on the switch. This was due to using "-b 100M" on
> the client (GBE), resulting in a bit rate of faster then 100Mbit including
> the overhead of the packets, which got much worse at smaller packet sizes.
> If too much data was transmitted switch buffers would overflow and packets
> would get lost. Now realizing that the -b option does not include headers,
> the -b option can be tuned to get close to the desired line rate.
>
> The idea is a line rate option would cause iperf to try to consider
> the size of headers and try to approximate (with a knowledge of the size of
> IP headers, UDP headers, checksum, etc) an average line rate rather than a
> data rate, for applications that would benefit from this. For our
> application we would then not need to worry about overflowing buffers and
> getting unexpected packet loss.
>
> This could all be done by in an application that calls iperf, but it
> would be nice if iperf could take care of this.
>
>
> thanks,
> Steve
>
>
>
> Kevin Gibbs
> <kgibbs --at-- ncsa.uiuc To: Steve.Brenne --at-- radisys.com
> .edu> cc: iperf-users --at-- dast.nlanr.net
> Subject: Re: bandwidth option ( -b ) in udp
> 01/23/2003 01:14
> PM
>
>
>
>
>
>
> On Wed, 22 Jan 2003 Steve.Brenne --at-- radisys.com wrote:
>
> > Is the bandwidth option in udp intended to represent the actual bit rate
> on
> > the line, or is it intended to only measure the rate of data transfer?
> > Would there be any value in an option that allows for the bandwidth to
> > represent either data rate or line rate. For my application I only care
> > about the line rate not about the data transfer rate.
> >
>
> I am not exactly sure what you are getting at here. The -b option
> specifies at what speed the client sends data to the server. As such I
> believe you would call that data rate. There is no way to measure the
> exact line rate. The best you can do is determine the highest data rate
> which will be close to the line rate. For example we have had TCP tests
> get 9.97 Mb/s on a 10Mb/s link so the 9.97 is approximately (and more
> importantly it is effectively) the line rate. I am not sure what you think
> iperf would do differently with a line rate option vs a data rate option.
> If you want to use UDP to determine line rate then send larger amounts of
> data than the line rate and look at the results seen by the server.
>
> Kevin
>
>
>
>
>