I’m pretty sure A&A would dig into this. They have their published "no b*llsh*t" policy and they can read a TCP protocol captured because that’s where the answer lies: the problem is why does TCP hate you so much and the answer is in: the precise timing of packets, packet loss, distribution of ACKs in time, per-connection field values, window sizes, buffer size, window scale, network pipe capacity, transit times so if someone looks at all that lot and has sufficient clue, then they can work out who is to blame within those two TCP instances.
It’s not good enough an ISP proving that their network has sufficient bandwidth by using a wise technique such as iperf or multiple TCP connections to saturate the link, because although those methods do accurately measure the network rather than the software implementation of TCP and o/s performance at the two ends, the behaviour of a single TCP connection is a ‘real world’ scenario that deserves a realistic expectation of performance, it’s not something wacky, highly unusable, or unrealistic.
I am possibly getting similar problems with the performance of upstream on my system with three internet access pipes, where there may or may not be multiple TCP connections in use in some scenarios. Many speed checkers, not just one, give disappointing values for upstream throughput, compared to the carefully calculated one for TCP PDU and TCP SDU (ie payload) total throughput. In the past the issue has varied markedly over time. It might be that the fact that there is one slow link out of the three is significant. But since there have been sizeable periods where full bandwidth has been seen, then I take it that that shows, as with you, that the network can handle the expected throughput which after all is extremely slow, we’re only talking about a few hundred kbps per link and 1.6 Mbps IP PDU throughput max; hardly challenging for multi-gigabit routers. I’m convinced the answer lies in TCP behaviour, but I don’t have the concentration or the experience to read TCP protocol captures, although I can obtain them.
I can’t remember; I may have talked to AA about this, but I haven’t pestered them to do the tcpdump analysis thing for me, because I haven’t had the energy to get into this, I’ll admit, and I’ve kept doing more digging and experiments myself. In my case not only is it AAs network but it’s also their router, a Firebrick, so that’s another big reason why I can indeed legitimately ask for help, as it may be that the Firebrick is not doing the packet tx scheduling over the three unequal links in a TCP-friendly way. And that’s a whole other can of worms that you don’t have. I could go back to them and get into it again but the truth is that I’ve been really unwell at times.