Re: A further question on using the -l option
Marcelo Maraboli wrote:
>> iperf -u -c 172.18.1.1 -b 90m -t 300 -l 100B
>
>
> you also used "-i 1"... ;)
Nope, got the results from what the server was seeing (it had the -i 1
option) but I wanted to show the client command that generated the data.
Sorry, should have made this clear.
>
>>
>> After a time I see the following from the server output:
>>
>> [ 6] 154.0-155.0 sec 7.01 MBytes 58.8 Mbits/sec 0.013 ms
>> 46088/119609 (39%)
>> [ 6] 155.0-156.0 sec 7.00 MBytes 58.7 Mbits/sec 0.018 ms
>> 43404/116817 (37%)
>> [ 6] 156.0-157.0 sec 6.31 MBytes 52.9 Mbits/sec 0.016 ms
>> 0/66157 (0%)
>> [ 6] 157.0-158.0 sec 6.33 MBytes 53.1 Mbits/sec 0.017 ms
>> 0/66423 (0%)
>>
>> The number of datagrams/s seems to lower and packets stop being
>> dropped or at least only a few get lost. The time to reach this point
>> seems to vary but it appears to be consistent behaviour if I repeat
>> the test. Is there any reason why the Iperf client would start to send
>> fewer packets, as this is what appears to happen, or am I mistaken
>> about what is happening?
>
>
> The standard test should be 60 seconds according to RFC 2544,
> but this behaviour means that something is "stabilizing" or that
> Iperf is not reporting correct numbers..
Looks like I need to try to find out why this is happening if there is
no obvious answer. We want to do some tests that last for a long time on
new fibre connections, hence didn't want things changing, or being
reported incorrectly, during the test.
Thanks for helping out with both questions,
Jim Mozley