fix burst mode throttle checking

[olichtne]

• Version of iperf3 (or development branch, such as master or
  3.1-STABLE) to which this pull request applies: master

• Issues fixed (if any):

While investigating a different iperf issue with udp stream tests I noticed that using -b 0/1000 results in iperf sending 1000 packets and then just idle for the remainder of the test duration.
The full command I was using to reproduce the issue:
iperf3 -c 192.168.101.2 -B 192.168.101.1 -b0/1000 -u -t 10 -l 1400

• Brief description of code changes (suitable for use as a commit message):

When burst mode is configured for unlimited rate (-b0) but with a
specific packet burst value, iperf only sends packets once, after that
the iperf_check_throttle function gets called and sets green_light=0
due to the rate value being 0 and average calculated rate always being
higher than that.

This can be fixed by moving the "don't throttle" condition
directly inside the iperf_check_throttle function.

Signed-off-by: Ondrej Lichtner [email protected]

[bmah888]

Thanks for the PR. I'm trying to remember what are the semantics exactly of doing burst mode on an unlimited-rate UDP transfer? In other words what's the difference between -b0 and -b0/1000? Without having thought about it a lot, it feels like both of them are supposed to spew packets out as fast as they can, so the idea of a burst size doesn't really mean anything.

[olichtne]

Yes, I also think that both are supposed to "spew packets out as fast as they can" which is the reason for my pull request. Which I assume means that the iperf_check_throttle function shouldn't be getting called with this combination of parameters.

On master, the condition for "should I do throttling" is only in one place - before calling the throttle function and in the send burst loop. However, the throttling function is also called after this loop at which point it calculates that the target rate '0' (as configured through -b 0) has been exceeded and red-lights the generation stream after the first burst.

This means that the -b 0/1000 combination basically only sends 1000 packets in a single burst and then does nothing until an end-condition is met, in case of an end condition for number of packets sent that just means it'll loop until infinity; in case a duration it'll wait until the expiration.

[olichtne]

I'll just repeat that this is related to the issue #899 where I can workaround slow udp generation by using the -b 0/1000 arguments together if I have this fix. I reported the issue separately as it might mean that a different fix is required for that, but if not then this does work as a workaround.

[bmah888]

Got it. I'm going to have to find some time to stare at this code for a little while (as well as your bug report in #899). Thanks.

[bmah888]

Ah, I finally get it. There are multiple calls to iperf_check_throttle(). Your point was that only one of them had the "skip throttling" condition around it, and it makes more sense to put the "skip throttling" check inside iperf_check_throttle() itself.

I tested this and it seemed to work correctly.

I wonder if another way to do this would have been to force burst to 0 if the rate was 0 when starting a new test. Your way is a little more robust, however.

Will merge this shortly.