Excerpts from Marco Dell'Anna's message of Fri Jul 23 03:55:07 -0500 2010:
> Is there any academic paper discussing the Iperf algorithm?

Hi Marco,

There is no Iperf algorithm to speak of.  Iperf simply tries to run traffic
across the network using either TCP or UDP.

The exact sequence of connections in Iperf 2 is not well documented.  This is
one of the things that was fixed in Iperf 3.  You can get an overview of the
Iperf 3 state machine at:

http://code.google.com/p/iperf/wiki/IperfStateMachine

The actual code may vary slightly from that, I think Seth may need to update
taht page still.

Otherwise, both Iperf 2 and Iperf 3 just open TCP or UDP connections and send
traffic.  For TCP the operating system handles everything internally.  The
details of TCP dynamics have been widely explored in academic papers.

For UDP Iperf accepts a -b flag which is the target bandwidth and attempts to
send traffic at that rate.  Iperf's current method of sending the data is very
bursty which may cause queuing problems when sourcing data on a network which
has significantly higher bandwidth than the destination network.  It should
also be noted that it is difficult, if not impossible, to precisely control
the bandwidth of the generated stream for a variety of reasons:

  1. if you sleep the granularity of the sleep times on most operating systems
     is not fine enough for higher speed flows.  That is, you can't sleep a
     short enough amount of time to send your traffic on time.  I don't have
     the exact numbers handy, but I could come up with them if it is of
     interest to anyone.  Even if the data rate is low enough fit within the
     granularity of the available timers system calls (such as sleep) can
     induce a variable amount of additional delay.

  2. Even if you busy wait (eg. no sleeping, no unecessary system calls) the
     system scheduler can induce unpredictable amount of delay by scheduling
     another process to run.  This can be mitigated to a limited degree by
     binding processes to particular cores, etc.  

The upshot is that a general purpose operating system is not suitable for
precise packet shaping.  However, Iperf's primary goal is to provide an idea
of what is achievable using a pair of systems running a general purpose OS, so
this may not be the end of the world.

This is probably not the answer you were looking for...

Let me know if you have any further questions,

Jon
-- 
Jon M. Dugan <jdu...@es.net>
ESnet Network Engineering Group
Lawrence Berkeley National Laboratory

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Reply via email to