If memory serves me right, Bob McMahon wrote: > The first sample shows 37.7Mb/s for iperf3 and 87.0 Mb/s for iperf2 > which is quite a big difference.
That is a significant difference, indeed. However in the original email, the iperf3 throughput was 87.6 Mbps measured at the receiver. I'm puzzled about the difference between the different iperf3 measurements. I wonder if we could also learn something more by seeing a dump of JSON output from the iperf3 client (this can be gotten by the -J command-line flag given to the client). > Nikita, it would be good to show more samples (maybe all of them?) as > well as both the client and server outputs. Also, to follow the TCP > ramp up w/iperf2 make a run setting -i to 0.01 (or 0.005) and the time > -t to 2 seconds. Again, use -e on both the server and the client. All > possible information helps. > > Note: I'm not sure if iperf3 uses setitimer > <https://linux.die.net/man/2/setitimer> or not nor if this platform > supports clock_gettime <https://linux.die.net/man/3/clock_gettime> but > here is a short timer program > <https://sourceforge.net/p/iperf2/code/ci/master/tree/src/timestamp.c> > which I use to verify timing (as well as timely reporting over ssh > pipes.) One can compile and run this on a platform to verify the > itimer fires as expected. iperf3 uses gettimeofday(3) for timing. I know this isn't exactly optimal but it's portable. I think we have an enhancement request open to use something better. Bruce. > On Tue, May 8, 2018 at 9:16 AM, Bruce A. Mah <b...@es.net > <mailto:b...@es.net>> wrote: > > If memory serves me right, Bob McMahon wrote: > > Hi Nikita, > > > > I don't know the iperf3 code. We've been maintaining iperf2 mostly per > > WiFi testing needs. Bruce's original response suggested internal timers > > not firing on time. > > Sorry for the radio silence...yes I think this is still the case with > iperf3, although I don't know *why* the timers aren't getting processed > at the desired time. I haven't come up with a good avenue for > investigating this yet. > > I would guess that the overall statistics are likely correct, just that > they don't look pretty. > > Bruce. > > > On Tue, May 8, 2018 at 12:26 AM, Nikita Gupta <nikitar...@gmail.com > <mailto:nikitar...@gmail.com> > > <mailto:nikitar...@gmail.com <mailto:nikitar...@gmail.com>>> wrote: > > > > Yes, iperf2 giving correct result. But can you explain why > *iperf3* > > is not showing data of 1 Sec but of 1.24 sec? > > > > On Tue, 8 May 2018 at 10:37 AM, Bob McMahon > > <bob.mcma...@broadcom.com <mailto:bob.mcma...@broadcom.com> > <mailto:bob.mcma...@broadcom.com <mailto:bob.mcma...@broadcom.com>>> > wrote: > > > > iperf2 seems to be indicating 83 socket writes per second with > > no write errors. The congestion window is 42K and the RTT is > > 3.5 milliseconds. Nothing seems too unusual to me. > > > > Bob > > > > On Mon, May 7, 2018 at 8:05 PM, Nikita Gupta > > <nikitar...@gmail.com <mailto:nikitar...@gmail.com> > <mailto:nikitar...@gmail.com <mailto:nikitar...@gmail.com>>> wrote: > > > > Yeah Bob, > > > > Input command for iperf 2.0.10: > > iperf -c <server addr> -e -i 1 -t 10 > > Output for iperf 2.0.10: > > [ 3] 0.00-1.00 sec 10.4 MBytes 87.0 Mbits/sec > > 83/0 0 42K/3464 us > > > > input for iperf3: > > iperf3 -c <server addr> -i 1 -t 10 > > Output for iperf3: > > [ 5] 0.00-1.24 sec 5.60 MBytes 37.7 Mbits/sec 0 > > 38.2 KBytes > > > > I'm facing issue of time interval with iperf3. > > > > On Mon, May 7, 2018 at 9:10 PM, Bob McMahon > > <bob.mcma...@broadcom.com > <mailto:bob.mcma...@broadcom.com> <mailto:bob.mcma...@broadcom.com > <mailto:bob.mcma...@broadcom.com>>> > > wrote: > > > > The client output for 2.0.10 with -e and -i 1 could > > provide useful information. > > > > Bob > > > > On Mon, May 7, 2018 at 1:32 AM, Nikita Gupta > > <nikitar...@gmail.com <mailto:nikitar...@gmail.com> > <mailto:nikitar...@gmail.com <mailto:nikitar...@gmail.com>>> wrote: > > > > Hi Bob, > > > > Working without issue: iperf-2.0.10 > > Time interval issue: iperf-3.3, iperf-3.1, > > iperf-3.5, iperf-3.0 > > > > Regards, > > Nikita > > > > On Sat, May 5, 2018 at 3:37 AM, Bob McMahon > > <bob.mcma...@broadcom.com > <mailto:bob.mcma...@broadcom.com> > > <mailto:bob.mcma...@broadcom.com > <mailto:bob.mcma...@broadcom.com>>> wrote: > > > > what version of iperf did you use? iperf -v > > should provide that. > > > > If it's a later version of iperf2 the output on > > the client of with the -e option could be > helpful. > > > > Bob > > > > On Thu, May 3, 2018 at 8:34 PM, Nikita Gupta > > <nikitar...@gmail.com > <mailto:nikitar...@gmail.com> > > <mailto:nikitar...@gmail.com > <mailto:nikitar...@gmail.com>>> wrote: > > > > Hi Bruce thanks for giving time on this > issue. > > > > I am working on an embedded system with > imx50. > > Server i'm using is RaspberryPi. Both the > > machines are connected on same network. > > > > Yes the system is a bit loaded. So this > > might be the reason. > > But if I reduce the window size then > > bandwidth also reduces and the time interval > > issue disappears. > > > > But with bandwidth of ~45M (which is the max > > it is showing) then it starts giving time > > interval issues. > > > > One more thing, I tried with iperf as well > > and its not giving any such issues on same > > machine with same server. > > > > On Thu, May 3, 2018 at 11:49 PM, Bruce A. > > Mah <b...@es.net <mailto:b...@es.net> > <mailto:b...@es.net <mailto:b...@es.net>>> wrote: > > > > If memory serves me right, Nikita > Gupta > > wrote: > > > Hi team, > > > > > > While checking network performance > > using iperf3, I'm facing interval > > > issue at client end. Below are > the logs: > > > > > > [ 5] 0.00-1.05 sec 11.2 > MBytes > > 88.7 Mbits/sec 0 42.4 > > > KBytes > > > [ 5] 1.05-2.01 sec 10.0 > MBytes > > 88.2 Mbits/sec 0 42.4 > > > KBytes > > > [ 5] 2.01-3.07 sec 11.2 > MBytes > > 88.4 Mbits/sec 0 42.4 > > > KBytes > > > [ 5] 3.07-4.05 sec 10.3 > MBytes > > 88.5 Mbits/sec 0 42.4 > > > KBytes > > > [ 5] 4.05-5.11 sec 11.2 > MBytes > > 88.6 Mbits/sec 0 42.4 > > > KBytes > > > [ 5] 5.11-6.06 sec 10.0 > MBytes > > 88.7 Mbits/sec 0 42.4 > > > KBytes > > > [ 5] 6.06-7.07 sec 10.7 > MBytes > > 89.0 Mbits/sec 0 42.4 > > > KBytes > > > [ 5] 7.07-8.02 sec 10.0 > MBytes > > 88.6 Mbits/sec 0 66.5 > > > KBytes > > > [ 5] 8.02-9.09 sec 11.1 > MBytes > > 86.8 Mbits/sec 0 112 > > > KBytes > > > [ 5] 9.09-10.06 sec 10.0 > MBytes > > 85.7 Mbits/sec 0 112 > > > KBytes > > > - - - - - - - - - - - - - - - - > - - - > > - - - - - - > > > [ ID] Interval > Transfer > > Bitrate Retr > > > [ 5] 0.00-10.06 sec 106 > MBytes > > 88.1 Mbits/sec 0 sender > > > [ 5] 0.00-10.12 sec 106 > MBytes > > 87.6 Mbits/sec > > > receiver > > > > > > I checked github bug #125 which was > > addressing this specific issue. But > > > no help. > > > I have tried iperf3.0.5, iperf3.1, > > iperf3.3, iperf3.5. In all versions, > > > I'm getting the same issue. > > > > > > P.S. Server(with same iperf3 > version) > > provides result as expected with 1 > > > sec time interval, but client > provides > > data at different time intervals > > > in every iteration. > > > Kindly look into the issue and > do let > > me know if m missing something. > > > > What are the command line > arguments you > > are using (both client and > > server side, sanitize them as > > necessary0? Also could you say > something > > about the environment you're running > > in? In particular, what OS and > > hardware on the client and server, and > > what kind of network path are you > > going over? > > > > I rarely see issues like this > (where the > > statistics printing intervals > > are not aligned to whole second > > boundaries) in the middle of a test, > > although it's been known to happen at > > the end of a test, for conditions > > that only happen at the end of a test. > > > > It seems like the timers within iperf3 > > that control when statistics and > > computed and printed aren't firing > when > > they're supposed to. On my > > laptop (MacBook Pro) this happens > close > > enough to the correct time that > > the timestamps appear to be exactly > > aligned to whole second boundaries > > (they're not, but close enough > given the > > precision of printing the > > values in the output). This situation > > could happen on slow hardware > > (some kind of embedded system?), on a > > virtual machine, or on a system > > that is very heavily loaded. We would > > need some more information to > > determine which of this is the > case (or > > whether it's something > > completely different). > > > > Bruce. > > > > > > > > > > > > > > > > -- > > Regards, > > Nikita Gupta > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community > on one > > of the world's most > > engaging tech sites, Slashdot.org! > > http://sdm.link/slashdot > > > _______________________________________________ > > Iperf-users mailing list > > Iperf-users@lists.sourceforge.net > <mailto:Iperf-users@lists.sourceforge.net> > > > <mailto:Iperf-users@lists.sourceforge.net > <mailto:Iperf-users@lists.sourceforge.net>> > > > https://lists.sourceforge.net/lists/listinfo/iperf-users > <https://lists.sourceforge.net/lists/listinfo/iperf-users> > > > <https://lists.sourceforge.net/lists/listinfo/iperf-users > <https://lists.sourceforge.net/lists/listinfo/iperf-users>> > > > > > > > > > > > > -- > > Regards, > > Nikita Gupta > > > > > > > > > > > > -- > > Regards, > > Nikita Gupta > > > > > > -- > > Regards, > > Nikita Gupta > > > > > > >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Iperf-users mailing list Iperf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iperf-users
