Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

You need to check what the rates are that are shown in clueless. As far as I am aware the default rate setting is 95% of maximum in order to make VoIP more reliable. This rate percentage is something that you can change yourself in clueless - see the drop-down menu near the top of the line settings. Be aware that on FTTC you need to subtract a certain amount for protocol overheads, below the sync rate, to get an actual IP rate. And then if you are measuring the TCP payload rate this will be appreciably less than the IP PDU rate (ie total bytes including IP headers).

The IP rate should be around 96.69% of the sync rate, but much less if the overheads due to a high setting of G.INP is operating. The rate for TCP payload as a percentage of sync rate is as follows for VDSL2 with G.INP in the normal setting and assuming 1500 byte IP PDUs (ie with a 1500 byte MTU; figures would be worse with a 1492 IP MTU):

IPv6+TCP+time stamps		92.05%
IPv6+TCP		92.822%
IPv4+TCP+time stamps		93.33%
IPv4+TCP		94.11%

This would be the best you could ever do for the actual time to download a file.

If it is TCP payload that is being reported, then 67 / 78 = 85.9% of sync rate, so compare that to the above figures. I think for the IPv6+TCP+Timestamps option at all 95% of the maximum rate setting then that would be about right  78 Mbps * 92.05% * 95% = ~68 Mbps.

If you are not using VoIP consider turning the rate up to 100%.

Could try downloading the test files from thinkbroadband, that would give you a real TCP payload rate (assuming it uses straight TCP, no tricks).

[Craig]

I'm not sure about anyone else here; but my rate is set to 100%. I have also set it to 110% with no change in actual throughput.

[PhilipD]

Hi

This is an interesting thread as I think I’m experiencing the same with AAISP. I sync at about 78. but any download only ever maxes at about 67 or 68. I’m not really complaining as it’s still 15mb more than I was getting with infinity, but it does seem as if there may be some issues on the TT backhaul?

This is what I'm seeing as well, I used to be able to get the full 75/76Mbps throughput available using TT backhaul via Uno, then a couple of months ago noticed I could never get more than around 70Mbps (often maxing out at 67/68) and a single threaded test drops from anywhere from 30 to around 50Mbps.

It appears TalkTalk (or is it Daisy now that has this business) has reduced everyone's speed by 10% regardless of peak or off peak, i.e. it's not natural congestion,

I'm surprised A&A aren't kicking up more of a fuss about it.

Regards

Phil

[Craig]

I contacted AA about this yesterday, and had the following response

Hello,

I've had a look and I'm afraid that the speeds are you are seeing are within our expectations and also the expectations of TalkTalk.

Unfortunately this is not something that would get much traction unless the throughput was below estimates.

I have asked what estimates they're using, because with my throughput being 67Mbps - as on their availability checker they display the TT Availability Checker as "Estimated download speed 69.66→80Mb/s." so my download is in-fact below this!

[ktz392837]

I always thought A&A were a premium provider.  This thread is certainly making me think why are people paying extra for what seems to be just a standard (or even sub standard) service? 

I certainly if I moved my Plusnet connection to AA and this was happening to me and after trying to get help I got that "go away" reply from customer services I would be thinking why did I move - Plusnet were better and 33%+ cheaper!

[johnson]

Lots of talk about estimates and then speed tests.

The useful data is your current line sync and if you have G.INP and whether that is retx high or low.

With the high variant expect ~90% of your sync as real throughput, compare this with tests.

 

[PhilipD]

Hi

In my case, as I stated else where, sync is 80/20, no interleaving and error rates are < 1 error seconds an hour sometimes none.

This thread isn't about sync speeds but actual throughput.  It seems TalkTalk backhaul has shaved around 10% of everyones throughput, i.e. if you get 74Mbps/sec a few months ago, now it never goes higher than around 67/68Mbps.

Regards

Phil

[Weaver]

@craig - can we have a recap - I got lost, and also I started talking about sotonsam’s numbers.

We can use the table I posted earlier (or I can adjust it for MTU 1492) to get a TCP payload result figure, if it is a TCP payload that you are talking about.

The thinkbroadband test by doing simple file downloads is a straightforward well-defined test, but it is not entirely AA-internal so if it underreads then that does not mean anything. Could check at very quiet times if day though and look for variability.

I need to check exactly what the figures are that you are using as I have got confused by the heat and drugs. 

[DaveC]

I seem to be experiencing similar issues with my TT VDSL line with AAISP.

The line reports max attainable around 80500/27300 and syncs at 80000/19999.  Ping to A&A's gateway is about 5.5ms.

However, running speedtest-cli has for the last couple of months not reported anything greater than about 68Mbits/s.  I'm sure this was managing something in the mid 70s previously, but don't have anything recorded.

As of earlier this week, I also have a BT VDSL line, which I'm bonding with that TT line, so this has let me do a few more comparisons.  This line reports max attainable around 77500/25000 and syncs around 77700/19999 (not sure how!).  Ping is slightly slower than the TT line at about 6.5ms

If I connect with only the BT line, I can speedtest around 71Mbits/s.  Enabling bonding gets me a download over 130Mbits/s.

Attached are the latest xdslcmd output from both lines.

[Weaver]

speedtest-cli goes to where? and is reporting TCP payload rate, not IP throughput rate?

Is there a chance that you are on G.INP high retx setting ? (which kitz says gives an efficiency of about 92% = IP PDU rate / sync rate, and then the IPvx+TCP headers both need to be subtracted from that again)

Before a lot of people start to chip in with me-toos we need to be very clear what terms we are using as TCP+IPv6 + TCP timestamps takes off 13% in the G.INP=high retx case.  It is 11.4% for IPv4+TCP+timestamps.

Also see the table posted earlier, for the usual case.

So one cannot just say my speed is x, without saying what stuff it is the speed of.

[j0hn]

That just over complicates things on a whole other level.
Sync rate, throughput. If retx is active, high or low?

The math doesn't work out right for me either

TCP+IPv6 + TCP timestamps takes off 13% in the G.INP=high retx case.  It is 11.4% for IPv4+TCP+timestamps

I get about 91% throughput from my sync speed, retx high.

[Weaver]

So you worked out that taking your TCP payload rate from a speed tester that figure comes out as 91% of sync rate?

Indeed, so does that mean that you are indeed on G.INP retx high?

And are you using IPv6 or IPv4 for for your speed tests?
Do you have G.INP? I am not even sure about that.

And I need to recap on what the tx rate figure shown in clueless is too.

[Weaver]

This is why we here are in danger of getting into a right pickle by not being really pedantic and precise about terms, because IPv6 + TCP + timestamps TCP payload rate is not the same at all as sync rate or IP profile or clueless.aa.net.uk’s tx-rate.

And adverts for ‘speed’ are absolutely hopeless because they never say what stuff it is the speed of.

ISPs need to be absolutely clear whether they are talking about sync rates or what. Sync rates are probably the best, because they are well defined. But they are not very helpful to the user as they need to be down-converted into something usable and so they are misleading. If you any of you are still on ADSL2+ or lower then the ATM efficiency of a mere 88.44% [in one typical case] is not good (that is, IP PDU rate = 0.8844 * sync rate ). If you are on FTTC then that efficiency figure is far, far better at a typical 96.69% IP PDU rate / sync rate [G.INP on, but on low setting], Kitz' figure. But in both cases you will always have to take off another big chunk if you are switching to talking about TCP payload rates (as in the true time to download a file, straight).

And speed testers are absolutely all over the place. You simply cannot trust them. If the whole network is really quiet then of course you can believe the results of a download of the thinkbroadband test download files. (Thinkbroadband has a speedtester, but I am not talking about that.)

Whenever you are doing any of these speed tests you need to check for alien traffic initiated by boxes in your own network. No one has mentioned this. AA users can do a traffic capture, triggered by a button in clueless, if unsure.

You also nee to check that you are not under attack. I took a look at the attacks I received over a 10 s period, from Russia, China, Italy, Ireland and the US. It was not a great amount of traffic,  up it is there. Another thing that a traffic capture will sort out.

AA staff should be checking this for you, not just telling you to go away. And they should be helping customers to get deconfused about the various numbers.

After you have checked your numbers, give RevK an email if customer service are being dismissive, or tell customer service to copy your email to him.

[PhilipD]

Hi

This is why we here are in danger of getting into a right pickle by not being really pedantic and precise about terms, because IPv6 + TCP + timestamps TCP payload rate is not the same at all as sync rate or IP profile or clueless.aa.net.uk’s tx-rate.

I'm not under attack and there is no other traffic on my network, I've confirmed this by viewing the traffic graph on my router and can see it's next to nothing.

I think you are in danger of over complicating things here.  The situation as reported by several of use now confirms that:

A few months ago, on TT back-haul via A&A and me via Uno, speed tests showed the maximum obtainable throughput at ~74Mbps, this seems to have been a consistent result by us posting here.

Then at a some point a few months ago, the maximum rate changed for all of us, and all we can achieve maximum is around 68Mbps, in all cases sync has remained unchanged for us here at 80/20 (in my case I hadn't even re-synced since the reduction as I had an up time of over 120 days).

Also I've seen single threaded tests drop drastically from around 74Mbps, to as low as 30Mbps, I've attached a speed test from just now and one from when things were working good.

Speed test from now:
https://www.thinkbroadband.com/speedtest/1530435655101510455

Last speed test I could find from this year prior to this slow down.
https://www.thinkbroadband.com/speedtest/1524204784771081555

It should be noted that the slower results I see now are unchanged anytime day or night, i.e. it's impossible to hit to 74Mbps, it's as though there is a permanent throttling of the connection.  The single threaded test is still much lower any time day or night, i.e. there appears to always be congestion, however there is no increase in latency or packet loss.  Basically it looks like the connection is being slowed deliberately to manage an oversubscribed network.

Now if this were PlusNet or some other budget provider it might not be too much of a surprise, however we are paying a premium for broadband expecting something better than a budget provider.

Regards

Phil

[spring]

if you tried all the servers in 1000km proximity to you, then 48mbit is your speed, disregard A&A as it purposefully displays an inflated speed

Basically it looks like the connection is being slowed deliberately to manage an oversubscribed network.

My ISP Bezeqint [Bezeq International] has distrubingly less total bandwidth than from the sum of all subscriber's plans and did not throttle in the past [minus a few days or months] nor currently.