Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Craig on June 14, 2018, 12:57:15 PM
-
Hey,
I recently moved from Plusnet to AAISP, nothing on my home network has changed and I still use my Billion 8900ax-2400. But on the 12th May between 13:00 and 19:00 something happened which has caused my download speeds to decrease by 5Mbps. This isn't a lot in the grand scheme of things, but it's annoying considering the speeds I used to get.
After contacting AA they have said that this is most likely due to "congestion on the open internet" as speedtest.net and fast.com always appear to top out at 67Mbps, but their http://speedtest2.aa.net.uk/ shows ~73Mbps... I've attached line stats and a screenshot from Sam Knows, anyone have any advice on what I can do?
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 24511 Kbps, Downstream rate = 79007 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79000 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 9.2
Attn(dB): 11.5 0.0
Pwr(dBm): -1.2 -1.2
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.0967 0.3771
L: 19856 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 198117635 54172648
OHFErr: 480 18
RS: 0 3519481844
RSCorr: 0 295
RSUnCorr: 0 0
Bearer 0
HEC: 3998 0
OCD: 130 0
LCD: 130 0
Total Cells: 3156476669 0
Data Cells: 1501971239 0
Drop Cells: 0
Bit Errors: 0 0
ES: 397 18
SES: 0 0
UAS: 28 28
AS: 331807
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.67 6.15
OR: 114.65 202.87
AgR: 79114.95 20203.27
Bitswap: 2544/2544 55/55
Total time = 3 days 20 hours 10 min 35 sec
FEC: 0 295
CRC: 480 18
ES: 397 18
SES: 0 0
UAS: 28 28
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Latest 15 minutes time = 10 min 35 sec
FEC: 0 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 20 hours 10 min 35 sec
FEC: 0 52
CRC: 115 4
ES: 98 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 106
CRC: 121 4
ES: 99 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 3 days 20 hours 10 min 7 sec
FEC: 0 295
CRC: 480 18
ES: 397 18
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
What does tbb.st do, same result?
-
Just done a tbb.st
(https://www.thinkbroadband.com/_assets/speedtest/button/1528978743140667255-mini.png) (https://www.thinkbroadband.com/speedtest/results.html?test=1528978743140667255)
-
Well I just did http://speedtest2.aa.net.uk/ 3 times and each time I'm getting results faster than my IP Profile.
So they appear to be exaggerating results.
Do you know if you use BTw or TTB with your AAISP line?
If BTw can you visit https://windows.mouselike.org/be/index.asp?DoAction=BrasChecker
and post the results.
-
That's interesting!
I am on the new TT backhaul
-
J0hn is right, the numbers are definitely exaggerated, my three ADSL2 lines’ combined rates reported by clueless (the lower figures, tx at 87% of sync rate, not the sync rates) come to less than the reported figure from that speed tester. Other speed testers exaggerate too, some far more and some go the other way possibly because that is what they really see, because of a poor network path or too much load on the server.
These servers ought to have an option to ask you what the maximum possible numbers are - they could ask for sync rate plus all your DSL parameters and calculate a fudge factor to de-rate the sync rate. That is what I do in a spreadsheet and in an iPad app that I have built which calculates upstream rate limiter settings and generates a snippet of a Firebrick’s XML config relating to PPPoE objects. That could be a sanity check / bull-tester for the speedtest app.
Also speed testers ought to measure the load that they are under and moan if it is too high so that that might affect the results and make it under-read. I also thing a speed tester should ping along the path between client and server for a fair while before the test begins and again afterwards, and maybe even briefly in between individual parts of a test sequence, so that spurious competing activity on the client’s own machine or own internet connection could be detected by disturbances to the latency. If the link is not quiet then the user ought to be told, or maybe the system could try waiting a little in case things quieten down while showing the user some sort of visual feedback about the quietness level related to alien traffic.
There are some test files for download at thinkbroadband (https://www.thinkbroadband.com/download) which gives you a straightforward simple measure where you know exactly what you are getting and what you are taking about, the straight TCP payload rate. It is of course not close to you like a test hosted by your own ISP would be, so it should be liable to under-read. If you did it in the middle of the night that should help a lot, as long as there is not such a long RTT that you are not filling the pipe and it has bubbles in it.
-
In my mind it's only related to how they calculate the displayed speed.
I don't know what transfer method that site uses but speedtest.net uses web-socket so that's best in my view. I'm saying this because I often encounter the phrase "flash testers are inaccurate".
-
well 1mbit of it may be explained by the sync speed, your current sync uptime is close to the time you said it dropped, and if you previously had a max 80mbit sync then thats 1mbit lost. The other 4mbit I dont know, could possibly be a ip profile issue within the AAISP network if they use such profiles.
-
Well I just did http://speedtest2.aa.net.uk/ 3 times and each time I'm getting results faster than my IP Profile.
So they appear to be exaggerating results.
Do you know if you use BTw or TTB with your AAISP line?
If BTw can you visit https://windows.mouselike.org/be/index.asp?DoAction=BrasChecker
and post the results.
make sure any a/v you have is disabled when running speedtests, any a/v that intercept's web traffic can skew speedtest results.
-
@Chrys - What do you mean by IP profile, Chrys?
@Craig - what does the recent clueless.aa.net.uk log look like? It will show you the tx and rx rates in use there, which is the real truth, not the sync rate.
You may already know that you can change the speed to be a certain percentage of this max rate. If it is set to 95% then that is for VoIP users to make VoIP reliable so if you do not use VoIP you can bang that up to 100% in clueless.
Craig when you say your download speed dropped by 5 Mbps on that date, do you mean sync rate or measured performance? If the sync rate dropped and took the performance with it then it could be a deterioration of the line, perhaps because a new crosstalker arrived, a new neighbour’s activity, or it could be a new source of RF interference or forty things.
You can try and do the usual things in your own house to optimise performance, such as getting rid of extensions, shortening wiring, using high quality faceplate-type DSL filters, high quality modem-to-wallsocket cables and short ones too, mains interference filtering. Going further, better modem or even shortening the run of internal wiring inside the house from the outside to the master socket by getting it moved, which would cost money and possibly be very inconvenient (or quite the reverse!). But on a line as good as yours, your signal will be strong so these kind of measures are much less likely to give you anything compared to the effect on someone like me with a 4.55 mile long [!] phone line and hence incredibly weak signal that is therefore very vulnerable to local noise sources which relatively will appear really loud. But crosstalk is going to be a big problem for you as for all FTTC users who do not have vectoring (anti-crosstalk systems).
Could you remind me of the sync speeds now and then?
-
IP profile is a name UK isp's use to basically determine a rate limit they set on customer's lines, apparently BTw require their customer isp's to set a ip profile on every line to match the expected throughput of the line. Plusnet e.g. have issues making sure this is set correctly.
Whether or not AAISP have any such profile set on ttb lines no idea, but this speed setting you just mentioned is a form of rate limiting so may be the answer.
-
@Chrys you were talking about what I thought you were talking about, good. I have BTW AA lines not TT ones. AA track BT with a certain delay and use a sync rate × some fixed fraction for ADSL2+/21CN I don't know about other systems. The have never got it wrong for me anyway, and when it changes you can see events logged in the 'clueless' control, logging and monitoring server, marked tx and rx rate. That system can, on request, also query the DSL for both sync rates plus other modem stats.
-
@Weaver - Here's all the entries from the logs on clueless where my Tx rate has changed. My sync rate has remained pretty constant but the performance has dropped as can be seen from the samknows graph. My line rate is set to 100%.
10 Jun 16:42:42 Tx rate (adjusted) 77830724 to 77551930 (rx 20000000) -Auto-
8 Jun 18:56:21 Tx rate (adjusted) 78529673 to 77830724 (rx 20000000) -Auto-
8 Jun 18:14:57 Tx rate (adjusted) 78517893 to 78529673 (rx 20000000) -Auto-
4 Jun 20:38:52 Tx rate (adjusted) 76959001 to 78517893 (rx 20000000) -Auto-
14 May 18:21:28 Tx rate (adjusted) 77363449 to 76959001 (rx 20000000) -Auto-
12 May 16:07:45 Tx rate (adjusted) 77143555 to 77363449 (rx 20000000) -Auto-
12 May 15:42:10 Tx rate (adjusted) 76393559 to 77143555 (rx 20000000) -Auto-
5 May 11:56:59 Tx rate (adjusted) 76424972 to 76393559 (rx 20000000) -Auto-
3 May 18:29:19 Tx rate (adjusted) 76676280 to 76424972 (rx 20000000) -Auto-
3 May 18:21:37 Tx rate (adjusted) 76770520 to 76676280 (rx 20000000) -Auto-
3 May 17:59:55 Tx rate (adjusted) 77174968 to 76770520 (rx 20000000) -Auto-
2 May 11:16:24 Tx rate (adjusted) 77614756 to 77174968 (rx 20000000) -Auto-
30 Apr 00:25:39 Tx rate (adjusted) 76770520 to 77614756 (rx 20000000) -Auto-
17 Apr 04:07:51 Tx rate (adjusted) 0 to 76770520 (rx 20000000) -Auto-
-
Craig the thing about ISP-external speedtesters is that they are mostly pretty rubbish, many just wildly impossibly off - see my threads about them in the past, plus the fact that it is not their fault but they can't be in control of the path between your ISPS and their test server. The ones I use are Ookla, SpeedSmart, or speedof.me or the tester at thinkbroadband not forgetting the big test download files plus a stopwatch at thinkbroadband (no software to lie or go wrong). I am an AA long-time customer and amazingly I never knew about that AA tester until your post. Duh. So good tip, thanks. Some testers let you select a server. Make sure that you pick one in central london near docklands where AA’s core networking hardware is, and try several of these until you find the fastest one with the highest performance figures and the lowest ping times. These tester apps’ idea of suggesting to you that you pick one near to you is utter stupidity but that is what many of them do.
What are the ratios between sync rates and the various speed testers mentioned plus the AA one?
Btw if you do a test, always do several and then keep only the fastest most favourable result, because alien traffic can slow the results down but cannot boost them.
-
I understand that congestion, routing issues etc can cause issues and speedtests can sometimes give wildly inaccurate results - my issue isn't with the odd result being off it's the obvious drop in the samknows results. That drop happened on the 12th May, and I moved to them on the 17th April, so something must have changed somewhere?
-
Apologies since you knew all that already. My experience with the obvious inaccuracies of speedtesters has made me extremely skeptical, that's all.
The question is where was the drop, was it further out than AA and what happened to your sync rate that day?
With the AA one this afternoon I got a variation of 14% just between two runs btw.
-
No harm done, completely understand where you're coming from. I'll have a deeper look at the data this evening :)
-
Well I just did http://speedtest2.aa.net.uk/ 3 times and each time I'm getting results faster than my IP Profile.
So they appear to be exaggerating results.
I just tried with my TT G.992.3 service (ADSL) and it reports results greater than my synchronisation speed! ::)
-
AA speedtest gives me 66/21
TBB speedtest gives me 60/16
And any other speedtest sites are more or less the same as TBB
So it looks like AA is giving incorrect readings.
-
Plenty of other speed testers give totally impossible figures.
A good way of making users think that that particular speed tester is the best because it is not slow, overloaded or on a bad pipe.
Also some users just like to feel good.
For an ISP though it is pretty naughty as it might make your users think their ISP is wonderful. It may make them feel that the reason that their own-ISP speedtesters reads high is because the path to it is short and ISP-internal, so does not have to go n hops over the rest of the internet across hops that are slow. A more clued-up user could work out thought that the speedtester in question reads high anyway because it is just inaccurate.
AA need to fix this.
-
I had no idea there even was an AA speed tester until I saw this thread recently.
For me the upstream is spot on. Downstream is very exaggerated, I make it 5% exaggeration which is quite a big error in my view. I got 8.39 Mbps combined download (don't know what that means, does that include TCP headers or TCP+IP headers or neither?). With one other well-known speed tester I get 8.01 Mbps which I think is probably fairly reasonable.
The sum of the AA ‘tx rate’ settings - the rate limiters reported by AA’s ‘clueless’ control server - comes to 7.9756 Mbps. (The tx rates are set currently to 99% of maximum as I wanted to see if I could improve responsiveness a little when trying to browse the web while a flat-out download is in progress but it has not worked.) That will be rate of the data transmitted including IP headers and TCP headers if any, so actual TCP payload throughput will be a good deal lower than that, say 2.67% for IPv4+TCP, 4% for IPv6+TCP and more if it is TCP with time stamps and other TCP options.
-
Hi
Hey,
I recently moved from Plusnet to AAISP, nothing on my home network has changed and I still use my Billion 8900ax-2400. But on the 12th May between 13:00 and 19:00 something happened which has caused my download speeds to decrease by 5Mbps. This isn't a lot in the grand scheme of things, but it's annoying considering the speeds I used to get.
After contacting AA they have said that this is most likely due to "congestion on the open internet" as speedtest.net and fast.com always appear to top out at 67Mbps, but their http://speedtest2.aa.net.uk/ shows ~73Mbps... I've attached line stats and a screenshot from Sam Knows, anyone have any advice on what I can do?
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 24511 Kbps, Downstream rate = 79007 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79000 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 9.2
Attn(dB): 11.5 0.0
Pwr(dBm): -1.2 -1.2
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.0967 0.3771
L: 19856 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 198117635 54172648
OHFErr: 480 18
RS: 0 3519481844
RSCorr: 0 295
RSUnCorr: 0 0
Bearer 0
HEC: 3998 0
OCD: 130 0
LCD: 130 0
Total Cells: 3156476669 0
Data Cells: 1501971239 0
Drop Cells: 0
Bit Errors: 0 0
ES: 397 18
SES: 0 0
UAS: 28 28
AS: 331807
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.67 6.15
OR: 114.65 202.87
AgR: 79114.95 20203.27
Bitswap: 2544/2544 55/55
Total time = 3 days 20 hours 10 min 35 sec
FEC: 0 295
CRC: 480 18
ES: 397 18
SES: 0 0
UAS: 28 28
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Latest 15 minutes time = 10 min 35 sec
FEC: 0 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 20 hours 10 min 35 sec
FEC: 0 52
CRC: 115 4
ES: 98 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 106
CRC: 121 4
ES: 99 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 3 days 20 hours 10 min 7 sec
FEC: 0 295
CRC: 480 18
ES: 397 18
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
That speed test is very similar to the one Uno use, which I've used to test as speeds have dropped when sync is the same (I'm with Uno).
All I will say is if I use my routers traffic graph whilst running the AAISP speed test, is they report a speed of 71.25, and my traffic graph shows total speeds of around 66Mbits/sec. if I run a Thinkbroad band test the throughput shown by the router matches pretty much the reported speed, at around 66Mbits/sec on the 6 x download. The test doesn't seem to report the real throughput.
Via TalkTalk backhaul that Uno uses (you may also be via TalkTalk on AAISP) speeds over the last couple of months have been pretty poor. I sync at 80/20 which has never changed, and speeds used to be 74/18 pretty much any time day or night, now speeds hover around 40 to 50Mbits/sec on the single download test, and no matter the day or night, I can never get over 65Mbits/sec on the single download test, it's like they've deducted 10Mbits/sec of the connection speed.
Regards
Phil
-
I agree that AA need to fix their speedtest - it's giving people an exaggerated result and this is especially bad if they're using this to mask underlying issues (knowingly or unknowingly) like Weaver said.
@PhillipD - I am on the TalkTalk backhaul, when using other speed testers and the weekly/monthly average, it's consistently 66.7Mbit/s - this is close to the same speed you reported so maybe we're experiencing the same issues! Mine did only start around 6 weeks ago (12th May).
-
Hi Craig
Possibly about the time I noticed. Speeds have dropped and I can never get full speed anymore, I'm beginning to think that TalkTalk have permanently taken away some bandwidth from those of us on 80/20 in order to help average speeds elsewhere on their network.
AAISP moved their customers over to a new network at TalkTalk, I'm not sure if I moved across or not given I'm with Uno, but it was about the same time speeds started showing a decline, no matter if off peak or peak times. Current speed test at Thinkbroadband shows single threaded at 48.5Mbps, multi-threaded at 69.3Mbps, so that indicates congestion, but it's not really low enough to complain about.
Regards
Phil
-
When I moved over to AAISP I requested to be put straight on the new TalkTalk network, and I was on it for about a month before I lost some of my speed. You're right it's not a lot of speed, but if they have decreased our speeds to compensate for others on the network is it going to continually get worse as they have to compensate more?!
-
Hi
Exactly it's a speed change going in the wrong direction and if we pay for an 80/20 product because we have a line that supports it and now it might only deliver half that it's not very good.
Will see how it fairs over the next couple of weeks then consider my options.
Regards
Phil
-
The speedtest A&A use is open source. The source is here: https://github.com/adolfintel/speedtest
May be worth opening a ticket if you can prove it's inaccurate.
-
Hi
Thanks for the pointer to the source.
One thing that jumps out looking at the code is the overheadCompensationFactor which is 1.06, this hasn't been changed on the Uno test (not looked at the AA one), but it means the speed is inflated so it isn't the actual TCP throughput its show but overall throughput.
For me, I just used the Uno test and got 70Mbps, if I divide by 1.06 to undo the correction factor, I get 66Mbps, which is pretty much what ThinkBroadband is showing for their x6 test. On this test 10 threads are used rather than 6 as used on Thinkbroadband.
So yes, it is inflating the result and is misleading.
Regards
Phil
-
I’ve noticed the last few times that I’ve done a speed test on Speedtest.net, seem to max out around 48Mb. Doesn’t seem to matter what server I try, whether it’s near me or a server in London. If I try the TBB speed test or DSLReports, I get what I expect, which is around 60Mb. Not sure whether it’s just down to Speedtest.net or whether A&A have a issue?
-
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?
-
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 (https://www.thinkbroadband.com/download), that would give you a real TCP payload rate (assuming it uses straight TCP, no tricks).
-
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.
-
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
-
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!
-
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!
-
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.
-
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
-
@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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (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 (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
-
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.
-
@craig - can we have a recap - I got lost, and also I started talking about sotonsam’s numbers.
I've attached the output from `adsl info --stats` on my Billion router.
In control.aa.net.uk; my rate is shown as 79.0M and Line Options (Rate) is set to 100%.
GEA Service Test
Test Description = GEA service test completed and no fault found .
Diagnostic Code = GTC_FTTC_SERVICE_0000, Sync Status = In Sync, NTE Power Status = PowerOn
Down Sync = 79Mbps, Up Sync = 20Mbps
REIN = Not Detected, Bridge Tap = Not Detected
Test Outcome = Pass, Main Fault Location = OK
Download speed from SamKnows (WhiteBox), Speedtest.net, fast.com and thinkbroadband all tops out at 67.7Mbit. AAs speedtester shows 72Mbit (but we know that's inflating numbers by 6%).
I've been speaking to some other AA customers on their IRC who have been experiencing issues as well (Hi Davec!)
Cheers,
Craig
-
I've also been speaking to some AAISP customers who have also noticed similar. Here is the out from my GEA:
Test Description = GEA service test completed and no fault found .
Diagnostic Code = GTC_FTTC_SERVICE_0000, Sync Status = In Sync, NTE Power Status = PowerOn
Down Sync = 77Mbps, Up Sync = 20Mbps
REIN = Not Detected, Bridge Tap = Not Detected
Test Outcome = Pass, Main Fault Location = OK
I don't really think we need to look at TCP payloads/G.INP or go into that sort of detail, I think that'll just end up overcomplicating it. (I'm on ECI, so don't even have G.INP, so that's not in the equation) The general noise from multiple people on TT Backhaul is that something is going on. It's odd that we all get similar throughput as well, mine never goes above 68Mbps on a speed test, just like it's hard set.
I contacted AAISP as I wondered if I had a lower bRAS profile set, but apparently there are no bRAS profiles on the TT Backhaul so that can't be it.
Again though, given that I was getting 50-52mb throughput before, I find it hard to moan to much....! But there does seem to be an issue for sure, which does raise the question as to if there is any point in paying for 'premium'.
-
If sufficient (A&A) customers request to be taken off the TT backhaul, as something is clearly not right, then perhaps A&A will actually take notice. :-\
-
If sufficient (A&A) customers request to be taken off the TT backhaul, as something is clearly not right, then perhaps A&A will actually take notice. :-\
Do they offer the BT backhaul with all their packages? I’m on their 1TB Home, and thought that was only available on TalkTalk.
Either way, I’ve been talking to RevK privately about this - I’ll keep you updated if anything materialises.
-
. . . I’ll keep you updated if anything materialises.
Thank you. :)
-
Moving from the old TT network to the new saw my TBB speed tests drop from 73 to 67 Mbps, with unchanged sync speed.
-
>that'll just end up overcomplicating it.
Well, if someone, I do say 'if', someone else maybe is mixing up tcp payload rates and sync speeds then they are not comparing like with like, and so speaking the truth requires necessarily complicating it. Much as people would sometimes like to ignore vital details and not have to think about them, doing so just means they will lead themselves into error.
`in each case, the question must be asked, what exactly is the figure that is being quoted referring to. And the speed testers do not say.
That does not invalidate what you are saying though!
From your numbers it seems that your speed is too low to be explicable by such confusion though. And I am in agreement that something needs to be looked into.
I am no help, because I am on BT not TT, have ridiculously low undemanding speeds and am also a ‘premium’ customer. I also have the issues of TCP subsystems interaction with IP bonding to consider, and there may be some loss of throughput because TCP receivers do not like packet reordering.
-
Very keen to hear the answer anyway. I am sure you will keep us informed.
I started off thinking this was about speed testers. It has turned into something much more besides.
-
Do they offer the BT backhaul with all their packages? I’m on their 1TB Home, and thought that was only available on TalkTalk.
Either way, I’ve been talking to RevK privately about this - I’ll keep you updated if anything materialises.
Yes, the 1 TB package is now available on BT - https://aastatus.net/2484 You can also now bond a 1TB TT line with a lower quota Home::1 line (something I've just started doing - a 1TB TT line and a 200GB BT line - the quotas balance automatically between the two lines).
Glad to hear you've been talking to RevK - good escalation!
-
I'm having this same issue of sync speed being 80mbit and seemingly only able to get 68Mbit throughput on Uno/Xilo on the TTB backhaul. BT line in same property is fine at 75Mbit
-
Hey,
I recently moved from Plusnet to AAISP, nothing on my home network has changed and I still use my Billion 8900ax-2400. But on the 12th May between 13:00 and 19:00 something happened which has caused my download speeds to decrease by 5Mbps. This isn't a lot in the grand scheme of things, but it's annoying considering the speeds I used to get.
After contacting AA they have said that this is most likely due to "congestion on the open internet" as speedtest.net and fast.com always appear to top out at 67Mbps, but their http://speedtest2.aa.net.uk/ shows ~73Mbps... I've attached line stats and a screenshot from Sam Knows, anyone have any advice on what I can do?
I'm looking in to this - happy to hear from other customers having similar issues, and also those with us on BT circuits who are/are not seeing issues. Email our support@ address FAO Andrew.
I have an iperf server that customers may test against - email in for info.
Thanks.
Andrew
-
I am pleased that someone from AA has replied to the thread.
I remember when Plusnet used to do similar but don't anymore so the fact that AA do means that is a positive when I weigh up options at contract renewal with my current provider Plusnet.
Back on topic is TalkTalk accidentally limiting to the new average download speeds that were brought in a couple of months ago instead of the maximum 80/20?
-
I remember when Plusnet used to do similar but don't anymore so the fact that AA do means that is a positive when I weigh up options at contract renewal with my current provider Plusnet.
i believe plusnet changed their policy so that their staff only participate (in an official capacity) on their own (flawed) forum.
-
Hi
I'm looking in to this - happy to hear from other customers having similar issues, and also those with us on BT circuits who are/are not seeing issues. Email our support@ address FAO Andrew.
I have an iperf server that customers may test against - email in for info.
Thanks.
Andrew
I'm with Uno but using TT backhaul and see the same capping to maximum speeds and overall poorer speeds on single threaded downloads, if you think it's worthwhile me running a test to prove/disprove this is a wider issue with TalkTalk backhaul, let me know, as symptoms seem identical.
Regards
Phil
-
Hi
I'm with Uno but using TT backhaul and see the same capping to maximum speeds and overall poorer speeds on single threaded downloads, if you think it's worthwhile me running a test to prove/disprove this is a wider issue with TalkTalk backhaul, let me know, as symptoms seem identical.
Regards
Phil
If you could raise this with Uno as I have Phillip so they can look into it as we are both having the same issues.
-
Had to quickly re-jig some bits my side, so had to resync'd my kit after a month. Interestinly my sync increased, I'm now pretty much max at 79 - but throughput on downloads hits exactly the same barrier at 68mb/sometimes 68.2mb. Doesn't matter what speed test I use, or if I download multiple files at once - I never never get over that magic 68!
I've contacted AAISP again as per Andrew's post above, glad they're looking into it. Somethings up, as with that sync I'd expect around 74/75mb throughput.
-
Welcome to Andrew for AA very good to have you on the forum.
-
It's interesting that other TT wholesalers may be seeing the same thing. We have an advantage in that we have customers on both TT and BT backhaul, and some customers with one of each who can test side-by-side. I have some iperf speed results from some of our customers, these are mostly TT circuits so far, I need some more BT ones for comparison. Whilst doing this, I have asked TT if they are away of anything, I'm awaiting a reply from our contacts there.
-
I really am no use since I have BT-only lines, have triple IP bonding to allow for and have incredibly slow modems. Otherwise I would volunteer.
-
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.
-
Since this thread is in the FTTC issues section, I was off-topic supplying my observations regarding the speedtester, file download times and my own figures since I am not an FTTC user. We did get sidetracked into talking about the speedtester web app further back. Also my apologies, and also that last post seemed to grow into a monster! ???
-
I really am no use since I have BT-only lines, have triple IP bonding to allow for and have incredibly slow modems. Otherwise I would volunteer.
I'd quite like some other A&A customers on BT VDSL to get in touch with me, as I'm wanting to test their speeds and compare... pop an email in to support@aa.net.uk if you can help.
-
Update: I've not yet seen a TT iperf3 result that is over 69M, even on lines with 79.9M sync. I do have iperf3 results on BT circuits that are over 70M though. So far I only a small sample of 20 circuits, 10 of each TT/BT. Tricky, as the difference in results in the TT and BT samples I have are narrow, but do show TT under performing in maybe 60% of cases compared to BT, it's more noticeable on lines with full or near 80M sync; it's as if TT have a 70M cap on the 80M circuits.
We do have a dialogue with TT on this, and they are not aware of a problem as of today, I've given them some example circuits and expect they will investigate further.
I'm aware that another TT wholesaler has seen similar problems (since mid May), they have have reported it to TT too, but hasn't had any progress.
-
Cheers for your updates Andrew. Glad you've been able to see a trend and have been able to forward this onto TT.
Let's hope they're able to do something about it!
-
Cheers for your updates Andrew. Glad you've been able to see a trend and have been able to forward this onto TT.
Let's hope they're able to do something about it!
It's a slight trend I'd say at this point.
-
Fyi, FTTC G.INP 80 Mbps sync rate corresponds to 73.64 Mbps IPv6+TCP+timestamps TCP payload rate, 92.049% of sync rate. This is the time taken to download a file. This is assuming that G.INP is turned on and at the low rate. With G.INP at the high retx rate then the speed will be far worse. With no G.INP then the speed is very slightly better. With IPv4 + TCP + timestamps the TCP payload rate is 74.67 Mbps, 93.338% of sync rate.
Sync rate is not the same thing as the AA ‘tx rate’ quoted in clueless, because the latter is lower, in order to account for DSL overheads due to bloat, from additional headers, ie extra data sent.
-
Hi
it's as if TT have a 70M cap on the 80M circuits.
That's exactly my thoughts on my Uno line on TT backhaul, it's what it behaves like, a cap on the maximum speed. Maybe this is by design, and they have a profile that sits lower than the maximum sync rate at 80/20. Or is it the case with every sync rate in that the maximum throughput is artificially lower than the sync speed is capable of and it's only obvious for those that are on 80/20 and are aware their maximum used to be ~74Mbps?
It maybe seems petty to complain about a loss of 4/5Meg and still getting >68Mbps, but it is a loss, and if it is some high-up decision for capacity reasons to knock back faster connections, then that is throttling, which in my case is not what my ISP is selling me so I lose out and the ISP loses out if they lose a customer. Also where does it stop, next month do they knock a bit more off to save buying extra capacity, then a bit more a few months later.
Will be interesting to hear what TT come back with.
Regards
Phil
-
I have the exact same issue (capped no matter time of day) and according to my logs it started approx mid May. I sent AAISP CS a very detailed email full of proof and even went to the length of eliminating the supplied FTTC modem.
I was dismissed that due to it not showing the usual signs of contention that there's "no problem".
A week later they did reply saying other customer TTB lines are already impacted, but by that point they'd weared my patience thin with all the outages during the daytime throughout last couple of months, and had already ordered VM Cable.
Early on in the contract I had issues with the line itself (80mbps -> 60mbps w/interleaving etc), and again I had to nag at them multiple times before anyone decided to action a BT Openreach engineer (who eventually discovered a wiring issue my side). Line was "in spec" even though it had actually fell beyond handback threshold at that point, FFS!
IMHO they have not lived upto their "reputation".
-
Welcome to the forum Orange4!
It is not good getting simply brushed off and told there is ‘no problem’, very frustrating.
Did you say that you have since switched to Virgin?
-
VM will be arriving in next few weeks - I delayed it due to going away for a week. Will axe AAISP as soon as that's installed and "stable".
-
We've asked TT to move a line to their older network so as to compare any differences. Should have some more info on that tomorrow. We're also looking at moving a line over to BT backhaul - but that would take two weeks to happen.
-
I've opened a status post our side:- https://aastatus.net/2530
Keep an eye on that for latest info - I'll post back here when there are more major milestones in this investigation.
-
Just an update on this.
I have been dealing with uno support regarding this since it happened in Mid May as user orange4 said I also had a line with AAISP and contacted them regarding this and was completely dismissed of this being an issue and that they werent willing to pursue this with TT. Needless to say I moved my other line elsewhere as the exp I had with the support team was arrogant brash and generally tried to belittle my understanding of the internet.
Uno have had my line moved to the previous TT network which has fixed all download speed issues.
Matt at Uno has been extremely supportive and pressed TT on this matter since day one.
-
Hi
I have been following this thread from the start even though I do not use AA
I do have sympathy with AA and their support, which without seeing their responses to the queries raised at the time I can appreciate if a service is running and showing no issues, it is not urgent and the support staff should be pleasant and respond so. However, in view of evidence given by customer, should have forwarded to second level at least for their review
The reason though for posting, after reading Andrew status page put up is this
How many people would prefer to lose 4/5mb and have very low latency (around 6ms I think compared to nearly 12ms on higher throughput)
There is one more issue with TT backhaul not mentioned, perhaps not noticed and that is email sending has been failing due to a brief disconnect/drop periodically, so much so, clients of ours using TT have been switched to BT lines
Many thanks
John
-
I've opened a status post our side:- https://aastatus.net/2530
It would be appreciated if you will please edit the post showing as "Update Today 17:57:01" and correct the spelling of the second word.
-
Hi
I have been following this thread from the start even though I do not use AA
I do have sympathy with AA and their support, which without seeing their responses to the queries raised at the time I can appreciate if a service is running and showing no issues, it is not urgent and the support staff should be pleasant and respond so. However, in view of evidence given by customer, should have forwarded to second level at least for their review
The reason though for posting, after reading Andrew status page put up is this
How many people would prefer to lose 4/5mb and have very low latency (around 6ms I think compared to nearly 12ms on higher throughput)
There is one more issue with TT backhaul not mentioned, perhaps not noticed and that is email sending has been failing due to a brief disconnect/drop periodically, so much so, clients of ours using TT have been switched to BT lines
Many thanks
John
I'm not sure this latency improvement is for all customers in all locations. The change from the new to old is 18ms instead of the 17ms it was. I gave AAISP the same details as I provided uno with only difference was uno were willing to push it further.
-
Hi
Sorry I have no knowledge of AA, not been a customer of them and only going by Andrew AA status page
As I said, your details should have at least been passed to second level for review or perhaps it was sorry
Many thanks
John
With the help of TalkTalk, this evening we tested a circuit via the old network. Although the latency increased (from 6.4ms to 11.8ms) the throughput as measured by using the iperf3 tool showed an increase from 67.4Mb/s to 71.9M/s. (This is a line with a 75.6M sync rate)
-
Will axe AAISP as soon as that's installed and "stable".
you might be waiting a while ! ;D
virgin can be very hit and miss, and you shouldn't expect the "advertised" speed at all times, conjestion can be a big with viring (just like other ISPs).
-
It would be appreciated if you will please edit the post showing as "Update Today 17:57:01" and correct the spelling of the second word.
Whoopz! Updated.
-
I'm not sure this latency improvement is for all customers in all locations. The change from the new to old is 18ms instead of the 17ms it was. I gave AAISP the same details as I provided uno with only difference was uno were willing to push it further.
Yes not all lines had reduced latency. Some did increase. There is work underway within the TT core network to improve latency - so we're expecting lines which increased latency to decrease once TT have finished this particular work. We've no eta, but to expect it to be this year sometime.
As for the 1st line response to your report and a couple of others customers who have reported similar things in the past month or so - we did miss this, and do apologise. We do have quite extensive monitoring of individual lines and have systems that report when it 'sees' congestion - the problem we had with the reports this time is that there was neither change in latency or packet loss and 3 or so reports over a few weeks (out of thousands of lines) wasn't enough to ring the alarm bells for these lines to have been escalated to our operations team.
This is something we can learn from - we're often at the forefront of diagnosing and reporting problems to backhaul carriers - it's one of the reasons we have our CQM graphs monitoring every one of our circuits.
We'll learn from this, and we'll get to the bottom of it too. :-)
-
Whoopz! Updated.
Thank you. :)
-
you might be waiting a while ! ;D
virgin can be very hit and miss, and you shouldn't expect the "advertised" speed at all times, conjestion can be a big with viring (just like other ISPs).
Fully aware - i'm on a 30 day rolling contract with VM for that very reason :cool: but i know for a fact the area has been resegmented, so i'll give it a try. If it beats 68mbps i'm happy !
-
Just an update on this.
I have been dealing with uno support regarding this since it happened in Mid May as user orange4 said I also had a line with AAISP and contacted them regarding this and was completely dismissed of this being an issue and that they werent willing to pursue this with TT. Needless to say I moved my other line elsewhere as the exp I had with the support team was arrogant brash and generally tried to belittle my understanding of the internet.
Uno have had my line moved to the previous TT network which has fixed all download speed issues.
Matt at Uno has been extremely supportive and pressed TT on this matter since day one.
Good to know about Uno should VM Cable prove to be a disaster (lets face it - real possibility), thanks for heads up.
-
Will Uno eventually have all it's users moved to the new TT network?
-
Currently my Uno Sync is 79999 @ 1.1dB SNR and am seeing a cap of 68 mbits. But if I use the Uno speedtester it indicates 72 mbits but before May the Uno speedtester was giving me 77 mbits download.
The reason I haven't reported to Uno is my attainable sync is 75 mbit as my SNR has dropped since the winter so if I re-sync it will be moot point.
-
Will Uno eventually have all it's users moved to the new TT network?
All of uno's customers are on the New TT network. I believe for now I am the only customer who has been moved back to the old network.
-
Hi
Currently my Uno Sync is 79999 @ 1.1dB SNR and am seeing a cap of 68 mbits. But if I use the Uno speedtester it indicates 72 mbits but before May the Uno speedtester was giving me 77 mbits download.
The reason I haven't reported to Uno is my attainable sync is 75 mbit as my SNR has dropped since the winter so if I re-sync it will be moot point.
The reason the Uno speed test provides a higher reading is the result is multiplied by 1.06, this is a default adjustment made by the open source code they use to cater for overheads (A&A use the same open source tester code and likely do the same thing), so that speed test isn't your data throughput, but overall throughput. Thinkbroadband (and other speedtesters like speedtest.net) report the actual data throughput which is more meaningful. Therefore if you take your 72Mbps from the Uno test and divide by 1.06 you get, wait for it, a spooky answer of 67.9Mbps.
The evidence is definitely there isn't it, TalkTalk is limiting the maximum throughput.
Regards
Phil
-
Hi
Will Uno eventually have all it's users moved to the new TT network?
I'm with Uno and had no notification of a move to the new network and only knew of it from A&A status page. Around the same time as the AA status page indicated users were being moved over that is when I noticed my speed tests slowed and I then appeared to have a throughput ceiling lower than the sync rate should provide. So I must be on the new network. It should be noted that prior to the move I had no issues with congestion or latency, and the new network probably increased overall pings and latency by a few ms.
Regards
Phil
-
Hi Andrew
Your speed test at http://speedtest2.aa.net.uk/ which uses the open source test https://github.com/adolfintel/speedtest has the default compensation factor applied of 1.06, so it reports (or tries to) the total throughput rather than actual data throughput, so it will always appear to be faster than other tests.
If you look in the Javascript code, in speedtest_worker.js and search for overheadCompensationFactor, setting this to 1 will give a truer speed test and comparable to most others. Currently at the moment for the TalkTalk ceiling we are seeing, the A&A speed test comes out as ~74Mbps (as does Uno's), whereas it is really ~68Mbps. It's almost as though TalkTalk have tuned their throughput settings to get 74Mbps on that test, which being inflated due to trying report throughput including overheads, has then resulted in everyone see a ceiling of 68Mbps.
Regards
Phil
-
I could do with a few (A&A) customers trying to max out their line, and then letting me know their login so I can review our CQM graphs.
...Our graphs records all sorts of data, including the throughput and when/if the line gets full - ie transfers traffic at the rate of the line. this is shown by red pixels at the base of the graph.
So far I have tested two lines, one line does not get the red pixels and one does - hence I need some more examples.
I suggest doing all of the following downloads simultaneously for about 15 minutes:
a) Download a torrent or two of a Debian iso (or similar) -
https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/debian-9.4.0-amd64-DVD-1.iso.torrent
b) Downloads of 1G files from these two places:
http://ipv4.download.thinkbroadband.com/1GB.zip
http://speedtest2.aa.net.uk/1GB.zip
c) Run iperf3 as well, a few times against our server (if possible)
d) run a Netflix speed test a few times:
www.fast.com
This should be done from a wired connection if possible, the speed testers will show low speeds due to all the other traffic but that's expected.
What we're looking for is the red line as seen on the bottom of this example graph: https://imagebin.ca/v/47cIr93UTAvP
Report back via support@aa.net.uk with subject: TalkTalk speed tests
-
Hi Andrew
Your speed test at http://speedtest2.aa.net.uk/ which uses the open source test https://github.com/adolfintel/speedtest has the default compensation factor applied of 1.06, so it reports (or tries to) the total throughput rather than actual data throughput, so it will always appear to be faster than other tests.
If you look in the Javascript code, in speedtest_worker.js and search for overheadCompensationFactor, setting this to 1 will give a truer speed test and comparable to most others. Currently at the moment for the TalkTalk ceiling we are seeing, the A&A speed test comes out as ~74Mbps (as does Uno's), whereas it is really ~68Mbps. It's almost as though TalkTalk have tuned their throughput settings to get 74Mbps on that test, which being inflated due to trying report throughput including overheads, has then resulted in everyone see a ceiling of 68Mbps.
Regards
Phil
I've set this to 1
-
I could do with a few (A&A) customers trying to max out their line, and then letting me know their login so I can review our CQM graphs.
...
Do you only need this for TT lines?
-
I've set this to 1
Just run another test on a BT 80/20 sync line. I have the line rate set at 100%.
-
Hi Andrew
I've just had a look and that hasn't changed in your speed test. This is because your test is pulling in the minimised file from http://speedtest2.aa.net.uk/speedtest_worker.min.js and not the more human readable one. I would suggest the easiest option is in the Html page change the line "w = new Worker('speedtest_worker.min.js')" to use the none minimised file (speedtest_worker.js) with the setting now set as 1 (Uno are using the non minimised version), and you then have an easy way to roll back to how it was if required, or perhaps set up a second HTML page using the non minimised version of that script so we can compare and contrast.
Regards
Phil
-
Do you only need this for TT lines?
Happy for BT lines too - it makes a good comparison.
-
Hi Andrew
I've just had a look and that hasn't changed in your speed test. This is because your test is pulling in the minimised file from http://speedtest2.aa.net.uk/speedtest_worker.min.js and not the more human readable one. I would suggest the easiest option is in the Html page change the line "w = new Worker('speedtest_worker.min.js')" to use the none minimised file (speedtest_worker.js) with the setting now set as 1 (Uno are using the non minimised version), and you then have an easy way to roll back to how it was if required, or perhaps set up a second HTML page using the non minimised version of that script so we can compare and contrast.
I've done that now!
-
Hi Andrew
Just testing that, and indeed it's changed now and reporting lower, however it's gone a bit too low. I've not got time to look at the code to see what it is doing, but currently my speed test shows as 64.98 with the factor at 1 (i.e. no change), I was expecting something around 69. If we take 64.98 * 1.06 it equals 68.88 which is what I would expect from that change. I'm guessing perhaps a bug in the test code is applying that correction factor twice and perhaps that is the bug, not the actual factor itself, therefore a factor of ~1.03 would correct that more or less. I'm guessing at the moment so I don't suggest changing it unless you want to, perhaps you would prefer to revert back to how it was?
All other speedtests are currently coming in around 68-69Mbps very consistently, the only exceptions are those based on the fdossena open source tester, I've tried Uno, yours, and even their own test page one at http://speedtest.fdossena.com/, they all report higher where dividing by 1.06 matches other testers.
Edit: Had a quick look at the Javascript and can't see this being applied twice, however the help documentation has:
overheadCompensationFactor: compensation for HTTP and network overhead. Default value assumes typical MTUs used over the Internet. You might want to change this if you're using this in your internal network with different MTUs, or if you're using IPv6 instead of IPv4.
Default: 1.06 probably a decent estimate for all overhead. This was measured empirically by comparing the measured speed and the speed reported by my the network adapter.
1048576/925000: old default value. This is probably too high.
1.0513: HTTP+TCP+IPv6+ETH, over the Internet (empirically tested, not calculated)
1.0369: Alternative value for HTTP+TCP+IPv4+ETH, over the Internet (empirically tested, not calculated)
1.081: Yet another alternative value for over the Internet (empirically tested, not calculated)
1514 / 1460: TCP+IPv4+ETH, ignoring HTTP overhead
1514 / 1440: TCP+IPv6+ETH, ignoring HTTP overhead
1: ignore overheads. This measures the speed at which you actually download and upload files rather than the raw connection speed
So 1 seems to be the true download speed, all the others are trying to estimate the overheads, and it can be seen from the notes that most aren't calculated, but arrived at by some guess work and observations. Interesting 1.0369 is listed as an alternative, which is what I suggested above would seem to give rise to something in the ball park of other testers.
Seems like this isn't a precise science where this tester is concerned, I wonder what adjustments are made by other speed testers?
There is a newer version of this tester code which has various bug fixes as well.
Regards
Phil
-
Yes, a bit tricky isn't it!
I've set it to 1.0369 for now, and have upgraded it to v4.5.4
Also, I was wondering if it was worth having a longer test, so there is now a 5 minute download test at
http://speedtest2.aa.net.uk/graph5.html
That is worth trying to see if speed changed as time goes on.
I've not tested this on a DSL line though.
-
I think care is needed now and no knee jerk changes made. You have changed the speed tester so that it is reporting less speed than what it was so if the TT network improves you can't compares figures. You may have even changed the tester so it is under reporting speeds now so it is still broken and any data collected with it before the change is now null and void. Urrgh.
-
Hi Andrew
Yes, a bit tricky isn't it!
I've set it to 1.0369 for now, and have upgraded it to v4.5.4
Also, I was wondering if it was worth having a longer test, so there is now a 5 minute download test at
http://speedtest2.aa.net.uk/graph5.html
That is worth trying to see if speed changed as time goes on.
I've not tested this on a DSL line though.
Hi Andrew
You are working quick, yes can see you've changed it to 1.0369, this is giving me around 70Mbps, which is much closer to all the other testers at around 69Mbps at the minute when I've just done a quick test around them. So certainly in the ball park now and seems more indicative of elsewhere.
The longer test flat-lines at the 70 mark as well.
Hopefully others can confirm this test is now matching others. I suppose the acid test is if you see tests that are not physically possible from an 80/20 sync, i.e. too high, which would indicate the compensation is slightly over compensating perhaps, but for now that seems to match other tests a lot better.
Regards
Phil
-
Hi
I think care is needed now and no knee jerk changes made. You have changed the speed tester so that it is reporting less speed than what it was so if the TT network improves you can't compares figures. You may have even changed the tester so it is under reporting speeds now so it is still broken and any data collected with it before the change is now null and void. Urrgh.
I think you have a fair point, but it was over reporting the speed. I think any tests will be checking more than just this one speed test, I came to the AA tester late on, but had already realised the Uno tester (same tester) was giving over inflated results. You can never go by just the one test, and A&A are making direct comparisons between BT lines, TalkTalk lines on the new network, and TalkTalk lines moved back to the old network. We've all definitely confirmed regardless of the raw number reported, that TalkTalk lines on the new work are running slower than they should be.
Regards
Phil
-
I think care is needed now and no knee jerk changes made. You have changed the speed tester so that it is reporting less speed than what it was so if the TT network improves you can't compares figures. You may have even changed the tester so it is under reporting speeds now so it is still broken and any data collected with it before the change is now null and void. Urrgh.
Oh, indeed - the speed tester is just an indication of the speed. We don't report a fault on the bases of results from speed testers - more work is needed to actually test the throughput of a line. Hence the posts above about downloads via bittorrent etc to try to fill the link, and then to compare that to what our own CQM graphs show. :-)
-
Also, I was wondering if it was worth having a longer test, so there is now a 5 minute download test at
http://speedtest2.aa.net.uk/graph5.html (http://speedtest2.aa.net.uk/graph5.html)
That is worth trying to see if speed changed as time goes on.
That's going to gobble up a lot of someone's allowance! (around 3GB?). A two or three minute test would probably suffice in most cases.
Could you have a box for the user to enter the number of minutes to run the test for?
-
That's going to gobble up a lot of someone's allowance! (around 3GB?). A two or three minute test would probably suffice in most cases.
Could you have a box for the user to enter the number of minutes to run the test for?
I'll give free top-up upon receipt of results :-)
-
Happy for BT lines too - it makes a good comparison.
Done - don't bother topping up mine - I don't need it.
-
So the author of the us was not helping matters when he included not only http+tcp+ipv6 but also ethernet, and the factors need to be different for ipv6 and ipv4 and depend on whether timestamps are enabled or not and on the MTU very slightly.
For MTU = 1500
| L3+L4+Options | TCP/IP header efficiency |
| IPv6+TCP+time stamps | 0.9520000 |
| IPv6+TCP | 0.9600000 |
| IPv4+TCP+time stamps | 0.9653333 |
| IPv4+TCP | 0.9733333 |
So in this case you want (1/the_above * http_factor), ie whatever is being used for http overhead, but I would imagine that is possibly negligible. However, assuming it is just too much of a pain to find out which is the case for the link in question, then I would simply use the 1/0.9520 figure for IPv6 with timestamps as it will be right for an ever increasing number of customers and we can fairly assume AA users anyway.
-
Some good news. TalkTalk have been doing some tests and changes on my home line as part of their investigations.
This is what we're looking for when looking at our CQM graphs of traffic:
https://imagebin.ca/v/47dpn502JjwS
A constant download of lots of http and torrents at 75.2M (sync is a bit below 76M), filling the link (red line at bottom)
iperf alone gives me 71.9 when I was getting 67.4 yesterday.
The change TT have made has only been applied to this one line, I'll update this post when the change has been made across the board.
-
It looks like this has been fixed, we'd appreciate any feedback
TalkTalk have rolled out a change to the "overhead accounting mode in use for VDSL customers." Customers can now try reconnecting (restart PPP or reboot the router), and try speed tests and downloads.
-
Hi Andrew
Tested without re-establishing PPP and same result with cap at 69Mbps, disconnected and immediately reconnected PPP and success, Thinkbroadband reports 75.1Mbps, back to normal.
https://www.thinkbroadband.com/speedtest/1530802264782102955 (https://www.thinkbroadband.com/speedtest/1530802264782102955)
Although some congestion given the single threaded test is lower, but then given the time of day.
Your own speed test is reporting 77.59Mbps, so still seems to over report.
Many thanks for sorting this out, should help push the old average speeds up for the marketing as well.
Regards
Phil
-
Your own speed test is reporting 77.59Mbps, so still seems to over report.
On the AA speed test you might need to force a complete reload of the page to not use a previously cached version of some of the scripts (CTRL+F5).
-
Hi Andrew
Tested without re-establishing PPP and same result with cap at 69Mbps, disconnected and immediately reconnected PPP and success, Thinkbroadband reports 75.1Mbps, back to normal.
https://www.thinkbroadband.com/speedtest/1530802264782102955 (https://www.thinkbroadband.com/speedtest/1530802264782102955)
Although some congestion given the single threaded test is lower, but then given the time of day.
Your own speed test is reporting 77.59Mbps, so still seems to over report.
Many thanks for sorting this out, should help push the old average speeds up for the marketing as well.
Regards
Phil
Phil,
As an uno customer did you not contact them regarding this? Even after I suggested to you just to provide them more details to pass to TT as they were already in the process of doing. I think uno deserve some credit here considering they have been trying to have this issue sorted with TT since mid may when it originally happened.
-
I think this thread shows that AAISP seemed to ignore customers early complaints and Uno took them more seriously.
However Uno have been at Talktalk about this since mid May and AAISP get talktalk to fix it within 48 hours.
It even fixed things for Uno lines.
What credit do Uno deserve for that? None imo.
Well done to AAISP here. Shame about the poor CS in the first place though.
-
Looks to be all back to normal to me - getting over the 72mb mark now.
Cheers Andrew @ AAISP for seeing this one over the line!
-
I think this thread shows that AAISP seemed to ignore customers early complaints and Uno took them more seriously.
However Uno have been at Talktalk about this since mid May and AAISP get talktalk to fix it within 48 hours.
It even fixed things for Uno lines.
What credit do Uno deserve for that? None imo.
Well done to AAISP here. Shame about the poor CS in the first place though.
We dont actually know the timeline and events of this problem behind the scenes, so we cannot say with certainty either way....
-
AAISP contacted Talktalk about this on the 3rd (https://forum.kitz.co.uk/index.php/topic,21750.msg377277.html#msg377277), fix was tested today (https://forum.kitz.co.uk/index.php/topic,21750.msg377429.html#msg377429) on AAISP Andrews home line, then rolled out to all lines (https://forum.kitz.co.uk/index.php/topic,21750.msg377430.html#msg377430) within an hour. It's all in this thread if you read the whole thing.
What other timeline do you need? Uno's 6 weeks failing to fix the problem is irrelevant.
poor CS by AAISP, great at getting the problem fixed with 2 days.
great CS by Uno, but unable to fix the issue within 6 weeks.
edit: big chunk of credit needs to go to the Kitz community as a whole. Without this thread the issue would likely still exist.
pat yourselves on the back folks :dance: :yay: :thumbs: :drink:
-
Hello,
We've been made aware of this thread by one of our customers so though it would be right to reply and add some more context.
I don't think it's fair to say that there was any failure by us because as orange4 says, a lot happened behind the scenes.
What did help overall is that there were a lot of AA users that were adding dialog here to compare their issue. There was the odd customer with us too. Sadly, the one or two customers with us that did see the issue didn't report it to us based on the posts here.
We had one solid report of the issue, which we didn't back down on. Another report but with throughput that varied wildly and one that was right most of the time. With this, TTB were working with very little information which looked like a single line fault. Had we had more lines, we'd have had more data.
We've spent several weeks arguing, fighting and pushing TTB. We've had their networks team on this, their head of networks; all checking configurations, showing us the output from switches and all of which seemed correct - they were being as transparent as they could be. They simply couldn't find the issue. If indeed the configuration change required is as now believed, it is as simple as few lines of config but could have been overlooked and may have just been due to a new pair of eyes checking it over and identifying it, or the configuration was as Juniper recommends which wasn't best for the use case.
Added: One of the first things we suggested to them was an incorrect CoS configuration on 14th May a day after the first report. They had concluded this was set correctly and the configuration of that and their NGE were all correct. They allegedly checked this again twice after that date around 2 weeks apart. The need to review and explain this lapse will be included in a report we've demanded they compile on the incident.
When we had the first report, we posted in a private group of which some ISPs are present who also use TTB to see if anyone else was impacted. We had no responses. This didn't help prove the issue to TTB, because as far as they were concerned, they had no other reports - which may very well be the case.
Only after a post by Andrew in that group a few days ago could we both approach TTB and show evidence the issue was bigger than we initially thought.
We offer a 40/10 service, and according to a post with Andrew today on that group, AA don't. We did not have any 40/10 user report this and from the understanding of the issue, those with lower-rate syncs would not have noticed. Even those customers who would have been impacted, might not be too worried about the reduction or as is evident, even report.
TTB are extremely hard to deal with when you believe there is an issue but only have the odd line affected (from those reported), so yes, whilst they did have more to work with because they then had another partner report the problem, I don't feel it's fair to say we deserve no credit at all.
For PhilipD, banger or anyone else with us, if you ever see a problem please do contact us. It would have helped us massively in getting a quicker resolution for all as has happened here. Additionally, we're automatically crediting those we can identify as potentially impacted for the full duration that we can correlate the issue to so please get in touch for that if you've not already had an email.
Matt
-
AAISP contacted Talktalk about this on the 3rd (https://forum.kitz.co.uk/index.php/topic,21750.msg377277.html#msg377277), fix was tested today (https://forum.kitz.co.uk/index.php/topic,21750.msg377429.html#msg377429) on AAISP Andrews home line, then rolled out to all lines (https://forum.kitz.co.uk/index.php/topic,21750.msg377430.html#msg377430) within an hour. It's all in this thread if you read the whole thing.
What other timeline do you need? Uno's 6 weeks failing to fix the problem is irrelevant.
poor CS by AAISP, great at getting the problem fixed with 2 days.
great CS by Uno, but unable to fix the issue within 6 weeks.
edit: big chunk of credit needs to go to the Kitz community as a whole. Without this thread the issue would likely still exist.
pat yourselves on the back folks :dance: :yay: :thumbs: :drink:
It's really not that simple, as Uno have just posted to confirm....
-
I would like to say thanks to Uno for the credit from May and should have raised this as an issue with Uno cs but it appears all fixed now and back to my usual speed tests.
-
Hi Matt
For PhilipD, banger or anyone else with us, if you ever see a problem please do contact us. It would have helped us massively in getting a quicker resolution for all as has happened here. Additionally, we're automatically crediting those we can identify as potentially impacted for the full duration that we can correlate the issue to so please get in touch for that if you've not already had an email.
Matt
I didn't raise it as an issue even though I had noticed this lowered ceiling in throughput back in May, simply because at that time, having seen the AAStatus page and issues mentioned there with TalkTalk needing to move users to a new network, I assumed it was because I was on the older network suffering from those problems, and partly expected it to resolve itself at some point soon, either because their old network had less connected users as they were moved off, or because everyone else gets moved across.
Also because their were no typical issues of problems like packet loss or latency ups and down and speeds were only 5 or 6 Meg lower than previously, it seemed slightly petty to complain, after all it is a contended service, and I also took the Uno speed test which reported 72-74Mbps which didn't help me have confidence in reporting anything, as I thought if I raised an issue and was told to take that speed test, it would show no problems. Of course later some investigation (by me having a poke around the code) seems to point to that speed test being a bit quirky, for example it's now giving me a result of 78Mbps (on the Uno tester), which I think is higher than the maximum possible speed it could ever be in practice on an 80/20 sync with VDSL.
I did check Uno status pages and dipped into the forum to see if there was any chatter about this back in May and on and off since and didn't see anyone else complaining or raise it is an issue.
Of course it was only seeing others report the same issues here that prompted me to join in, where it became obvious at that point I had probably joined the new network and that it was the new normal.
I think it would have been helpful if Uno had emailed customers on TTB that they were moving over to a new network build, as at that point we all would have probably fed back an "Aye up, somethings not quite right on this new network". As it was, I didn't know I had been moved, and just worked it out later. If I had known in advance of the switch over, I would have done a few speed tests before and after just to see, and would have reported back there and then, and I suspect others would have done the same.
We got there in the end, although I find it incredible TTB themselves didn't notice anything untoward.
Regards
Phil
-
I've noted the speedtest comments and we've been testing for the last few weeks some alternative versions. Please do get in touch via the portal as i'd like be able to identify you, check we've identified your line as one we believe was impacted and then alter your portal account to use the new test.
I think it would have been helpful if Uno had emailed customers on TTB that they were moving over to a new network build, as at that point we all would have probably fed back an "Aye up, somethings not quite right on this new network". As it was, I didn't know I had been moved, and just worked it out later. If I had known in advance of the switch over, I would have done a few speed tests before and after just to see, and would have reported back there and then, and I suspect others would have done the same.
I'd entirely agree although we had test lines on the new network months before this and they showed no issues. Likewise, all our customers had moved over to this well before the start of May. They trickled over as new sessions were started as to not cause any downtime or outage by forcing sessions to reconnect.
Part of the report we've requested is a log of all changes that they will have in the change control for the network. There were two drops in throughput we saw around 12/13th May, although the first to the second wasn't as large as the first, we suspect there was an alteration which was rolled out without testing although to be clear, this is solely speculation at this time from the data from the limited information we had.
Our immediate suspicion to CoS was an earlier customer that had an issue in March/April where their throughput was limited to less than 1/4 of their sync. No other reports and that would have been far more noticeable. This was a CoS issue on a TTB switch which they fixed after a few days and was, as they claim, human error.
I don't want to hijack the thread too much as largely the basics have been covered but do invite any of our customers to get in touch to discuss in more detail as well as alternative LLU options that we're working on.
Matt
-
I'm wondering if I'm affected by this speed issue since I'm with uno and on the TT backhaul. My speed is usually around 68Mb/s. One thing I noticed from swapping from BTW to TTB is that my DS SNRM won't drop to a 3db margin, which it did when I was on a BTW service. Just wondering if anyone else has noticed this.
Steve
-
The SNR wouldn't be impacted by this, that's down to DLM and controlled by Openreach.
If you were getting 68Mb throughout but your sync is full rate, try reconnecting otherwise do raise with us and we'll get everything checked.
Matt
-
Hi Matt,
I used to sync at 80/20 when I was on the BTW service with a 3db SNRM, but ever since swapping to a TTB service in Jan 2018, Openreach's DLM hasn't even tried lowering the SNRM which I accept there's nothing that can be done about it except wait and see if the DLM relents.
That's why I haven't raised an issue about it in recent months. :)
Steve
-
Absolutely nothing they can do about that.
I don't know if they are allowed to request DLM resets because the snrm target hasn't been lowered under the current DLM reset trial (I doubt it).
When you switched from BTw to TTB you effectively had a DLM reset.
Usually G.INP is applied within a couple days and the snrm target lowers a couple days after that. Now and again it just doesn't do as it should. It completely skips G.INP on some random lines despite being on a Huawei cabinet. A DLM reset fixes this.
If you were able to get a DLM reset (don't know what the criteria is OpenReach ask for) then chances are it would lower the snrm target within the week.
Completely unrelated to this threads issue and just 1 of those things with DLM.
-
My thanks to everybody who reported and progressed the problem. My download speed is back to what it was on the old TT network.
https://www.thinkbroadband.com/speedtest/1530839129821744055
-
>Shame about the poor CS in the first place though.
Indeed. CS should not start to get dismissive / jaded / complacent. I would assume they have a lot of bull to deal with and whinging customers but unfortunately that is part of the job (although hopefully they might meet more customers with clue at a techy ISP such as AA).
I get the feeling somehow that AA staff have a lot on their plates. Signs of of being overworked include a minor lack of maintenance on website content, some has been rather out of date in the past, though better nowadays. Another thing is the AA ideas list - too much work in the queue means some good ideas never advance and sit there for years. It might be that a some more bodies would help the staff out a bit, take the pressure off.
The thing here is the contrast between a human operation such as AA and XyzVastco.net ISP where you can never get to a human being with a brain, just a zombie reading from a script acting as a corporate firewall, and you never know who any of the worthwhile people are. And here we have a problem detected, then zero red tape, AA staff just swung into action and fixed it. A “well done” to Andrew and to AA.
It's very weird, the idea of someone moving to VM in search of consistent speed ! They may very well sometimes be fast, but is often just a lottery from the rumour mill. If someone is with AA and is are not satisfied with their lot then I suspect that they are never going to be happy. :-)
I myself have absolutely zero interest in maximum speeds, random high speed when you are lucky and the gods smile on you. It is minima that I care about. That is one of the dozen reasons why I have zero interest in the fixed long-range wireless system that is available in the village. As a shared service you have absolutely no clue what the performance is going to be like from one minute to the next and no recourse if you do not like it other than to walk.
[Moderator edited to fix an incorrect auto-correction!]
-
https://www.thinkbroadband.com/news/8101-uk-broadband-speed-test-results-for-june-2018
Median of 239.4mbps is fairly decent. On a 30 day rolling contract I think its worth a try. Trading consistency for ability to burst where possible.
-
@orange4 they really are getting some spectacular speed figures nowadays. Is that figure with FTTP now then? Or to be more exact their weird system with almost all fibre optics and tiny bit of coax at the very last for compatibility reasons?
-
@orange4 they really are getting some spectacular speed figures nowadays. Is that figure with FTTP now then? Or to be more exact their weird system with almost all fibre optics and tiny bit of coax at the very last for compatibility reasons?
That's Coax DOCSIS 3.0 tech, and yes fibre all the way upto Coax. Some very new deployments are FTTP then Coax converted for compatibility reasons (!!)
FWIW modern platforms, be it media, gaming are getting very data greedy. You pay your money and take your chances...
-
VM's stuff is good when it works. Don't expect useful customer support. If there's a flaw with the hardware they supply you're stuck with it, even if you're a business customer (google "Puma 6"). If you don't get the speeds you're supposed to, you'll probably not have any luck getting it fixed. You'll get a reference number and a review date. At the review date, nothing will change, and you'll get another review date.
It's a shame that in many areas VM have a monopoly on "superfast" broadband.
-
Don't forget the various Xdb attenuators, :D.
-
VM's stuff is good when it works. Don't expect useful customer support. If there's a flaw with the hardware they supply you're stuck with it, even if you're a business customer (google "Puma 6"). If you don't get the speeds you're supposed to, you'll probably not have any luck getting it fixed. You'll get a reference number and a review date. At the review date, nothing will change, and you'll get another review date.
It's a shame that in many areas VM have a monopoly on "superfast" broadband.
That's if you can even get them to acknowledge that there is fault. Usually, they just bury their heads and proclaim there is nothing wrong. At peak times, I was having issues with upstream congestion which resulted in the upload speed being half of what it should of been (20Mb) and the latency being appalling. But nope, apparently there was nothing wrong. This was the thread I had running: https://community.virginmedia.com/t5/Speed/Intermittent-congestion/td-p/3562884
When the connection worked with VM, it was fairly decent. Any problems and you're pretty much left on your own, as their "support" is basically non-existent.
-
@unocomms - and welcome to the Kitz forum unocomms. It's very good to have you! I keep hearing lots of good things about uno
-
Matt and co are always very helpful when issues arrive, an excellent ISP to be with as I've been with uno since 2011. :)
Sorry for going slightly OT here.
Steve
-
Can I ask if anyone on TT circuits are seeing slowness problems again, or are speeds still reaching top speed? Thanks.
-
Can I ask if anyone on TT circuits are seeing slowness problems again, or are speeds still reaching top speed? Thanks.
Non dedicated Thinkbroadband speed test may be a little slower than it was downstream.
Date Down HTTPx6 Down HTTPx1 Upstream
Fri 10/08/2018 01:56 73.36 Mbps 72.76 Mbps 18.61 Mbps
Fri 10/08/2018 01:56 73.63 Mbps 72.29 Mbps 18.44 Mbps
Fri 10/08/2018 01:52 73.20 Mbps 72.73 Mbps 18.19 Mbps
Fri 06/07/2018 02:06 74.08 Mbps 72.73 Mbps 17.96 Mbps
Fri 06/07/2018 02:05 74.22 Mbps 72.73 Mbps 18.00 Mbps
Fri 06/07/2018 02:04 73.51 Mbps 73.09 Mbps 18.44 Mbps
Sync speed unchanged: Connection speed (kbps): 79999 19999 :cool:
-
Can I ask if anyone on TT circuits are seeing slowness problems again, or are speeds still reaching top speed? Thanks.
Seem to be getting around 75mb throghput on a line sycned at 79999 - so seems to be ok.