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>
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> 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> 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
>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>
>>
>


-- 
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
https://lists.sourceforge.net/lists/listinfo/iperf-users

Reply via email to