Kitz Forum
Chat => Tech Chat => Topic started by: Weaver on December 15, 2020, 11:08:19 PM
-
I have now once again seen the highest reported downstream speedtester figure ever:
- speedtest2.aa.net.uk 11.0 Mbps / 1.52 Mbps
- Ookla speedtest.net 10.4 Mbps / 1.56 Mbps
The upstream figures is exceptionally good too. That is not an upstream record for speedtest2; that stands at ~1.55 Mbps, recorded some while back. The recent Ookla upstream figure is consistent with that of the speedtest2 at 1.56 Mbps, and the similarity between the two gives me increased confidence in both. The figures reported in all cases are the highest across many tests.
Earlier on, for some reason, I had been consistently getting very uninspiring upstream numbers from both the AA speedtester and the Ookla speedtest.net at around 1.15 Mbps. The testmy.net speedtester however had been consistently reporting around 1.35 Mbps upstream.
Live sync rates, 2020-12-20:
#1: down 3122 kbps, up 528 kbps
#2: down 3004 kbps, up 570 kbps
#3: down 2927 kbps, up 392 kbps
#4: down 3238 kbps, up 570 kbps
[[Update: downstream figure updated in the light of a later test.
Update: upstream figures updated. 2020-12-20.]]
-
So your four bonded lines give you a throughput of approximately twice the throughput which I experience.
[bcat ~]$ speedtest-cli --simple
Ping: 51.859 ms
Download: 4.98 Mbit/s
Upload: 1.02 Mbit/s
[bcat ~]$
-
@Burakkucat: I didn’t know your downstream was as high as that, or I’ve forgotten.
Update: a later test with speedtest2.aa.net.uk gives 11.0 Mbps downstream, which is truly amazing considering just a few weeks ago the reported figure was around 9.5 Mbps (very approximately).
Efficiency and exaggeration: I added up the per-line Tx Rate figures for my lines as reported by the clueless.aa.net.uk control server and found that the sum of the downstream tx-rates = 10923570 bps, so my case demonstrates that the speedtest2 exaggerates downstream slightly, since my reported 11.0 Mbps = 100.7% of the tx-rate-total. A point of interest: this possibly suggests that speedtest2.aa.net.uk tries to report IP PDU bytes, not TCP payload data bytes. If we assume that the speedtest2 reports TCP payload data bps then some conversion from IP PDU bytes to/from TCP payload would need to be carried out.
This result suggests that AA’s downstream IP bonding is highly efficient.
-
@Burakkucat thank you for the useful tip about the speedtest-cli tool. I got some excellent results with this when I ran it on my Raspberry Pi
speedtest-cli --simple
Ping: 47.896 ms
Download: 10.03 Mbit/s
Upload: 1.71 Mbit/s
I don’t get anywhere near the same downstream values but the upstream values are really high compared to the other speedtest tools. This is after only a few runs.
[[ Update: upstream updated in the light of later tests. ]]
-
Hmm . . . :hmm:
I believe I am remembering correctly . . . Quite a while ago we, the Kitz community (not just you and me), after some specific testing, came to the conclusion that the speedtest2.aa.net.uk site was consistently exaggerating the displayed throughput rate.
-
It certainly seems to read high on mine, about 50Mbps over on the download, and about 2Mbps over on the upload
-
I had got it into my head that the exaggeration had been fixed, but it seems not so. I reported it to AA some while back.
On another point: speedtest-cli gives very high upstream results: 1.71 Mbps for me. This is 98% of the IP egress rate of 1.744 Mbps at my chosen modem loading factor of 0.95 and a protocol efficiency of 0.884434.
-
In all honesty, I do not trust the absolute value returned by any "speed tester".
My method of operation is to choose one throughput speed test and then consistently use it . . . only considering the delta between the currently returned data and the data previously returned.
-
Agreed. I feel that way too.
If we could trust speed testers to some minimal level, that is not to knowingly tweak values for the purposes of exaggeration, then we could just take the highest reported value and that would be pretty good.
-
Just use fast.com
-
I have attached full stats for all my lines, in a zip file, for anyone who’s interested.
My line 4 downstream is 10% faster than that of the slowest line, at an amazing downstream 3.2Mbps sync rate. I wonder why. There are no obvious defects, rather, it’s the other way around.
Live sync rates:
#1: down 3122 kbps, up 528 kbps
#2: down 2997 kbps, up 535 kbps
#3: down 2927 kbps, up 392 kbps
#4: down 3238 kbps, up 570 kbps
-
Thanks to Gigabitethernet for the tip about fast.com; I did not know of that service. It’s interesting that it’s completely broken: first test, with defaults gave 10.0 Mbps down / 3.8 Mbps ups that was with a minimum of 4 maximum of 8 parallel connections. That upstream reading is wildly impossible as the maximum upstream is 1.744 Mbps. Out of interest, I changed the settings to: 8 connections min, 16 max and the results became even more absurd with 24 Mbps being reported for upstream!
The defaults are ridiculous because it reported that it was using a server in Seattle. I changed the default from "English (US)" to "UK" and that caused the server to change to Dorking. The upstream results were still wildly ridiculous though at 12 times the maximum possible!
So I certainly won’t be using that again. Shame because if the bugs were fixed it might have some promise.
-
Works absolutely fine here, sorry.
-
I have attached full stats for all my lines, in a zip file, for anyone who’s interested.
The ZIP file has a size of 0 bytes. :(
-
I have had another attempt at attaching the zipfile.
-
@Gigabitethernet the Downstreeam figure which I got was plausible. It was the upstream figure that was completely ridiculous. What upstream do you get ? And if you change the number of parallel connections do you see an effect?
-
Fast.com gives me a result of 150/52.
Not bad for a 160/30 package.
Fast.com always gives me results above what are possible, particularly the upstream.
The absolute maximum throughput I've had on this package is 149/31.
-
J0hn, do you have FTTP? So it returns a ridiculous 52 Mbps for you when the package quoted maximum is 30 Mbps?
Same pattern as for me then, plausible downstream, ludicrous upstream.
-
Yes I'm on BT FTTP (160/30).
I do actually get 31Mb/s throughput on the upstream despite that being above the quoted package limit, but nowhere near the 52Mb/s that fast.com quotes.
-
Well I have no issues, reports 7Mb up which is fine
-
I’m assuming that the fast.com tester perhaps doesn’t like out-of-order delivery, that’s the only thing I can’t think of, seeing as my line #3 upstream is so very slow compared to the others. But it is beyond crazy, how they manage to get things an entire order of magnitude wrong.
-
Likely not, isn't j0hn also having issues.
-
Good point.
-
I have attached full stats for all my lines, in a zip file, for anyone who’s interested.
I have now successfully downloaded a copy and will process the contents, etc, when time permits.