I ran the Andrews and Arnold LibreSpeed speed tester to look at ‘real’ upstream TCP payload (I think, just guessing, payload rather than IP PDUs, so the IP payload which is the meaningful value as regards assessing the link itself will be somewhat higher than this value.) An
amazing value of 1.86 Mbps upstream was obtained, the all time record by a long way. The link speeds are a bit odd in that link #1 is about 100kbps faster than has ever been seen before. looking at the predicted totals, the speed obtained should be impossible as it is above the 96% MLF and even the 100% MLF predicted values (terms are defined below). The measured rate is 105.52% of the prediction at current MLF, and 101.30% of the rate at MLF of 100%.
How can an such a large improvement in efficiency be obtained? Seems like magic!
If I add a further amount still in order to account for TCP headers and either IPv4 or IPv6 headers and possibly TCP timestamps used in the AA speed tester, then that makes the mystery even harder to resolve. Mind you, the speed tester could already be tweaking the results by adding an extra amount to allow for the data sent in the headers on top of the payload values, but that would require introspection and a detailed knowledge of the actual L4/L3 protocols in use at the time of each test even including MTU values.
============ * Current upstream speed rates used by Firebrick * ============
The Firebrick's internet access links have the following
upstream speeds (expressed as IP PDU rates) right now:
#1: 546792 bps
#2: 450849 bps
#3: 321792 bps
#4: 443207 bps
Total combined rate: 1.762640 Mbps
Fractional speed contributions:
#1: 31.021% [██████████████████████████████████████████████████]
#2: 25.578% [█████████████████████████████████████████ ‒‒‒‒‒‒‒‒]
#3: 18.256% [█████████████████████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#4: 25.144% [█████████████████████████████████████████ ‒‒‒‒‒‒‒‒]
- These are the upstream data rates on each link sent by the Firebrick given as IP PDU rates. These values are always well below the upstream sync rate of each link because of overheads due to protocol layers below layer 3. The reduced upstream rate given here is the theoretical maximum calculated for a link in the most optimistic possible scenario, one based on sending large packets of a certain chosen size. The quoted upstream rate is also further reduced by multiplication by a certain chosen 'modem loading factor', whose value is based on experience, tuned for best upstream performance.
Breakdown and detailed predictions :
Link | Sync upstream | MLF | Protocol efficiency | Fudge factor | IP rate | Max rate (100%) | Fractional contribution |
L1 | 644000 | 96% | 0.884433962 | 0.849056604 | 546792 | 569575 | 31.0212% |
L2 | 531000 | 96% | 0.884433962 | 0.849056604 | 450849 | 469634 | 25.5781% |
L3 | 379000 | 96% | 0.884433962 | 0.849056604 | 321792 | 335200 | 18.2563% |
L4 | 522000 | 96% | 0.884433962 | 0.849056604 | 443207 | 461674 | 25.1445% |
Totals: | 2076000 | | | | 1762640 | 1836083 |
Test date:
2020-06-27.* Column headings explained:
* The
Modem Loading Factor (MLF) is an upstream egress rate multiplier chosen to maximise throughout without overloading the link.
*
Fudge Factor is defined as the MLF times the protocol efficiency; the overall multiplier to convert sync rate into IP PDU egress bit rate at the actual chosen MLF.
* The ‘Max Rate’ (100%) is the IP PDU egress bit rate that would be the case if the modem loading factor (MLF) were set to 100%.
* The ‘IP rate’ is the IP PDU egress bit rate at the actual chosen modem loading factor (96% in this case).
* The ‘fractional contribution’ is the contribution of each link rate as a fraction of the total.
Live sync rates of modems currently (obtained by querying modems directly):
#1: down 2719 kbps, up 644 kbps
#2: down 2716 kbps, up 531 kbps
#3: down 2825 kbps, up 379 kbps
#4: down 2828 kbps, up 522 kbps
Notice that line 1 sync rate upstream is freakishly high, no modem has hit such a high u/s value ever before. Line 3 is as usual really slow, a continuing problem. Lines 2, 4 are as normal, as expected.
There is a large variance in the upstream rates reported by this speed tester, as with other testers, nothing unusual about that. other upstream results recorded today were; 1.53 and 1.21 Mbps. I suppose these low numbers could be the result of traffic on my internet connection, or the AA tester server could be busy. My policy is always to disregard everything and take the maximum as the only value of interest, seeing as undesirable effects can reduce the rate but cannot increase it; the maximum is the true capability of the link, disregarding any other traffic in it, or protocol-related effects such as the performance of TCP - other transport layers might give spurious differing results for the supposed link capacity. I want a measurement of overall bonded link capacity not the performance of some particular arbitrary transport protocol. There’s also the efficiency of the Firebrick router’s load splitting capabilities using each of the links to the optimum according to what it can truly handle.