Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 [3] 4 5 ... 10

Author Topic: Speed issues with AAISP  (Read 5325 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6109
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Speed issues with AAISP
« Reply #30 on: June 30, 2018, 12:45:19 AM »

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 stamps92.05%
IPv6+TCP92.822%
IPv4+TCP+time stamps 93.33%
IPv4+TCP94.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).
« Last Edit: July 11, 2018, 05:57:59 AM by Weaver »
Logged

Craig

  • Just arrived
  • *
  • Posts: 13
Re: Speed issues with AAISP
« Reply #31 on: June 30, 2018, 10:59:01 AM »

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.
Logged

PhilipD

  • Reg Member
  • ***
  • Posts: 375
Re: Speed issues with AAISP
« Reply #32 on: June 30, 2018, 11:28:55 AM »

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
Logged

Craig

  • Just arrived
  • *
  • Posts: 13
Re: Speed issues with AAISP
« Reply #33 on: June 30, 2018, 11:33:29 AM »

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

Quote
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!
Logged

ktz392837

  • Reg Member
  • ***
  • Posts: 373
Re: Speed issues with AAISP
« Reply #34 on: June 30, 2018, 12:41:45 PM »

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!
Logged

johnson

  • Reg Member
  • ***
  • Posts: 495
Re: Speed issues with AAISP
« Reply #35 on: June 30, 2018, 12:58:39 PM »

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.

 
Logged

PhilipD

  • Reg Member
  • ***
  • Posts: 375
Re: Speed issues with AAISP
« Reply #36 on: June 30, 2018, 04:56:40 PM »

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
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6109
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Speed issues with AAISP
« Reply #37 on: June 30, 2018, 05:22:32 PM »

@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.  ;D
Logged

DaveC

  • Member
  • **
  • Posts: 71
Re: Speed issues with AAISP
« Reply #38 on: June 30, 2018, 10:26:47 PM »

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.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6109
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Speed issues with AAISP
« Reply #39 on: July 01, 2018, 12:06:57 AM »

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.
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 1806
Re: Speed issues with AAISP
« Reply #40 on: July 01, 2018, 12:30:08 AM »

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

Quote
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.
Logged
BT FTTC 55/10 ECI now Huawei cab
Zyxel VMG1312-B10A bridge mode with 1508 MTU + Asus RT-AC68U running Asuswrt-Merlin

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6109
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Speed issues with AAISP
« Reply #41 on: July 01, 2018, 12:36:54 AM »

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.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6109
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Speed issues with AAISP
« Reply #42 on: July 01, 2018, 12:57:30 AM »

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.
« Last Edit: July 01, 2018, 01:01:01 AM by Weaver »
Logged

PhilipD

  • Reg Member
  • ***
  • Posts: 375
Re: Speed issues with AAISP
« Reply #43 on: July 01, 2018, 10:12:28 AM »

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







« Last Edit: July 01, 2018, 10:16:38 AM by PhilipD »
Logged

spring

  • Reg Member
  • ***
  • Posts: 322
Re: Speed issues with AAISP
« Reply #44 on: July 01, 2018, 10:15:41 AM »

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.
« Last Edit: July 01, 2018, 10:23:08 AM by spring »
Logged
No one knows what is the taste of the void.
Pages: 1 2 [3] 4 5 ... 10