Can we test both on the 'RTT' column here:
log_time; rx_load; tx_load; baseline_RTT; RTT; delta_RTT; cur_dl_rate; cur_ul_rate; 20211119T210141.632780922; 0.00; 0.10; 45.59; 47.88; 2.29; 25000.00; 25000.00; 20211119T210142.543874758; 0.02; 0.36; 45.59; 47.95; 2.36; 25000.00; 25000.00; 20211119T210143.573865440; 0.02; 0.67; 45.59; 48.43; 2.84; 25000.00; 25050.00;
I would like to see how with this real RTT data set this alternative routine compares in terms of how it adapts the baseline RTT. Maybe we need a larger data set though.
I'm a bit dubious about the importance of the RTT baseline. For my LTE connection it stays around 50ms. Some tests on my mobile phone show similar values in completely different locations. We have discussed above someone driving around, but that sounds like a pretty extreme case!
For most use cases, so long as RTT adjusts UP very slowly, isn't the EWMA with a constant that takes say 15 mins to adjust just fine?
As @moeller0 observed above, if baseline RTT is underestimated, this means punishing the bandwidth increase a little bit, which is not so bad because we still avoid bufferbloat then. Viewing this whole concept as a kind of 'turbo' function against the bandwidth that would otherwise be set (based on worst case bandwidth scenario) in CAKE, we are still offering an increase over what would otherwise have been set. Just perhaps not as much as would be available.
In stark contrast, by allowing baseline RTT to increase too quickly, we introduce the danger of letting through bufferbloat by overestimating the true baseline RTT. If we try to squeeze too much we introduce the possibility of letting lemon pips (or in our case bufferbloat) through:
Seems like the safe bet is slow RTT increase and fast RTT decrease.
Set against this backdrop, as for EWMA vs this two-pole butterworth filter, what benefit would the latter give in terms of 'reacting faster to changes'?
A complexity is that the RTT we look at has an increase associated with bufferbloat, and we need to avoid capturing the increase associated with bufferbloat in the baseline. Would the two-pole butterworth be good at that?
The present approach at least seems to handle the above issue well:
20211119T210541.207899347; 0.78; 0.08; 45.01; 49.69; 4.69; 34332.00; 25000.00; 20211119T210542.207050486; 0.77; 0.09; 45.01; 48.33; 3.32; 34557.00; 25000.00; 20211119T210543.253130538; 0.75; 0.09; 45.06; 91.12; 46.11; 32307.00; 25000.00; 20211119T210544.345748622; 0.69; 0.07; 45.15; 134.99; 89.93; 30057.00; 25000.00; 20211119T210545.464845349; 0.48; 0.05; 45.46; 358.24; 313.09; 27807.00; 25000.00; 20211119T210546.274829760; 0.82; 0.06; 45.46; 47.49; 2.03; 28032.00; 25000.00;