Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[FR] An idea for improvement of the bandwidth measurement in live mode #2968

Open
ethouris opened this issue Jun 26, 2024 · 0 comments
Open
Labels
[core] Area: Changes in SRT library core Type: Enhancement Indicates new feature requests
Milestone

Comments

@ethouris
Copy link
Collaborator

The main problem with bandwidth measurement is that it is defined for sending always 15th and 16th packet in a row, regardless of anything else. In case of "stowed sending" (like in file transmission) this isn't a problem, but in live mode it is rarely a case when you can really have two consecutive packets 15th and 16th already in the sender buffer when attempting to send the 15th.

The most reliable idea would be to have a confirmation flag placed in the 16th packet that this packet really can be taken for measurement. But this requires more changes, including changes in the protocol.

Another possibility, which can be implemented in live mode, is to rely on the clock differences in the packets' timestamp, and accept some (possibly configurable?) maximum delay time. If the difference between 15th and 16th packet in time is less than this, this pair can be treated as measurable, otherwise it's rejected.

This should use the following: if the sender queue picks up the 15th packet, it should prevent it from being sent at the predefined time and reschedule it (define a sleep time for the next action) for some small defined time. When next time this packet is retried, it should be checked if the 16th packet is already in the buffer; if not, just send this packet anyway, otherwise, as the 16th packet is already there, send the 15th and 16th immediately one after another. The maximum delay time should be also greater than the time distance of these two consecutive packets and it should be stated by the receiver that if this time distance really doesn't exceed the maximum delay time, this pair should have been sent with these preconditions in mind, and therefore it can be taken for measurement, otherwise rejected.

Of course the flag should be still better for the receiver to be more certain about the ability of the packet to be taken for measurement, but this maximum delay rule can at least increase the chance of taking correct measurements in live mode.

@ethouris ethouris added the Type: Enhancement Indicates new feature requests label Jun 26, 2024
@maxsharabayko maxsharabayko added this to the Parking Lot milestone Jun 27, 2024
@maxsharabayko maxsharabayko added the [core] Area: Changes in SRT library core label Jun 27, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
[core] Area: Changes in SRT library core Type: Enhancement Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

2 participants