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