You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: