new feature: UDP packet rate ?
On Thu, 5 Aug 2004, Kevin Gibbs wrote:
> > Jim Mozley wrote:
> > > So I need to script a wrapper to set the correct -b option given a -l
> > > value so I allow for the overhead, assuming I want a constant wire rate.
> >
> Actually you are quoting my post ever so slightly out of context. It is
> true that there is no _programatical_ way to before hand compute the
> amount of headers, i.e. Iperf will never be able to do it. However a
> user (or more likely network admin) can "easily" compute this
> information before hand. The caveat being if you are sending data over the
> Internet in general then you will not be able to calculate it. If you know
> exactly the path that every packet will take and what those network types
> are then you can calculate the header size. For instance if I have 2 GigE
> (or 10 or 100 Mb/s ethernet link) cards connected over a crossover cable
> then I know that the headers (and footers) are ethernet, IP, UDP. Even if
> I threw in a ethernet switch I would still get the same headers. However
> if I connected two machines directly through a ATM link I would get a
> different set of headers. Since Iperf can not detect these link types or
> any along a multi-hop path it can not provide the functionality you are
> looking for. You should be able to provide it yourself given you know your
> setup.
Granted, a "wire-rate" command line option for iperf is probably not a
Good Thing. However, I thought there is something good that iperf
could do to help a lot: a new "packet-rate" option, which would
directly pace the sendmsg() system calls in UDP mode.
Today, Jim's wrapper script (see above) would have to compute this
packet rate more or less directly, then convert it to UDP bitrate,
feed it to iperf, which converts it back to a packet rate (because
iperf obviously sends UDP packets, and not UDP bits). A packet rate
command line option would skip those two steps, making the whole thing
easier and less error-prone (especially for the wrapper script ;-)
Morever, I suspect there wouldn't be much to implement. As opposed to
some wire bitrate option, this one would be simple and clean, needing
no fuzzy logic (like: "mmmm, let's say we have IP+Ethernet headers").
And finally, I am sure some people are sometimes actually more
interested in the packet rate itself than in the wire bitrate or UDP
bitrate, so they would be pleased too.
What do you guys think about this ? Should I start coding ?
Cheers,
--
"Je n'ai fait cette lettre-ci plus longue que parce que je n'ai pas eu
le loisir de la faire plus courte." -- Blaise Pascal