From the AA speedtester, I get 8.29 MBps with IPv4 and 8.11 MBps with IPv6 but the numbers are up and down all over the place, so I have quoted the maxima from a number of runs. The speed tester unfortunately doesn't say what that quote figure means though: if it is quoting TCP payload throughput then it needs to say so, plus whether it is using IPv6 or IPv4 currently and whether or not TCP timestamps are on. I am assuming that is an IPv6 or IPV4 TCP payload result as indicated by the type of ‘my address’ shown and that it is ‘with timestamps’ because the latter is what my iPad seems to prefer. I would have to get a traffic capture to find out. I found you don't care about such details as timestamps then your results will be approx 1% inaccurate, you will be seeing numbers that are low.
What we all really need is IP PDU throughput and TCP ought not to be involved, as we should not be concerned with slow start or dropped packets and retransmissions or weirdness in the face of PDU recording in my case.
Using the file download I see an IPv6 TCP payload throughput (am assuming with timestamps) that is 7.27 Mbps, which was derived by taking the 200 MB download time (230s), subtracting the 100 MB download time (120s) which gives us a 100 MB time without the slow start and the quoted figure is from that, 8 * 100 MB / (230-120) s = 7.27 Mbps. The speed tester is clearly under load sometimes so that it is essential to take the best result. Do not do an average, it is statistically invalid anyway.
For me, all clueless ‘rates’ are set to 100% currently, so there should be no problem about the definition of terms. My current _sum of AA ‘tx rate’ figures_ is 7.93 Mbps, so the speedtester results are impossible, being 2.27% and 12.48% exaggerated.
The sum of sync rates is 9.02 Mbps. From that, my calculated protocol maximum IP PDU rate is 7977593 bps based of theoretical calculation down from sum of sync rates using the known protocol overheads from PPP inclusive down to the ATM AAL5 CPCS and ATM cell overhead. AA is clearly using a slightly lower rate figure than that, which is a good idea since their routers remain in control, not BTs and it saves them money on a possible small amount of traffic dropped by BT anyway. The right figure for AA to use is related to whatever number BT uses, not my theoretical overhead fraction calculation. The value of the ratio that BT uses just has to be discovered somehow but calculation will not deliver it.
My file download payload rate is 96.3% of the sum of AA ‘tx rates’ when the latter figure is down-converted from an IP rate to an IPv6 TCP + timestamps payload rate (by multiplying by 95.2%, from the ratio of the payload sizes assuming 1500 byte IP PDUs and the IPv6 + TCP header bloat including typical TCP options when timestamps are enabled). So that means that the whole system of IP bonding even with TCP errors, retx and dropped packets is pretty good then at 96.3% of the maximum possible with the AA rates set as they are.
If you want to do the file download test, you need to get your current AA TX rate from clueless.aa.net.uk and multiply it by 0.952 for IPv6 or 0.965333 for IPv4 to obtain a TCP payload transfer rate and only the latter should be compared with the download time. You should do several downloads and keep the best time. For a more accurate result, try the subtraction method that I used, to get rid of slow start.