Extending PR #1821 fix to PR #1773 for sending when bitrate is set#1848
Merged
swlars merged 1 commit intoesnet:masterfrom Mar 5, 2025
Conversation
Contributor
|
Looks good! Thanks for the pull request. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Version of iperf3 (or development branch, such as
masteror3.1-STABLE) to which this pull request applies:master
Issues fixed (if any): regression introduced with #1821: bitrate drop to zero #1847
Brief description of code changes (suitable for use as a commit message):
Further fix to #1773 that was partially fixed by #1821. This fix here is making sure that after sending, the conditions for green light will be evaluated if no message was send. The issue was actually caused by wrong copy/paste (did not copy the
|| message_sent == 0) 😞...@bmah888, not that this seems to be a quite urgent issue. It happens with short packets much more frequently (this is why I didn't find it in my tests). My understanding is that this is because the long enough delays between packets, the micro-sleep mechanism resolution is good enough, and the delays between packets are bigger for large packets.