Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Cecil_rfc on October 21, 2022, 01:59:51 PM
-
Hi all,
New to the forums and have done lots of (very interesting!) reading about FTTC and how it all works.
I've just moved from EE to a new ISP, as EE said my line couldn't go any faster than being banded at 40/10. Since I've moved to my new provider, my speed has increased slightly but still not to what I expecting.
Currently my download speed is like this from Speedtest:
Download = 39.66 Mbps (this has been around 41Mbps over the last 24 hours)
Upload = 13.12 Mbps
When I type my address into https://www.broadbandchecker.btwholesale.com/#/ADSL/AddressFeatureProduct I can see that my figures are as follows:
Downstream Line Rate Upstream Line Rate Downstream Handback threshold
High Low High Low
VDSL Range A (Clean) 59.3 40.7 13.3 8.5 35
VDSL Range B (Impacted) 57.8 35 13 7.8 30.7
Then when I check my router stats:
Upstream Downstream
Current Rate (kbps) 14156 47901
Max Rate (kbps) 14085 64083
SNR Margin (dB) 6.2 6.1
Line Attenuation (dB) 4.9 13.9
Errors (pkts) 24 0
Should I be getting faster speeds than I am getting? I'm using a wired connection so not connecting to wireless.
Also, my next door neighbour (semi detached) is with Sky and showed me a screenshot of his speedtest on his phone which showed his download as 59Mbps. We are both using the same exchange, and actually when you put his address into the bb checker, his speeds are LOWER than what mine are. This all makes no sense to me.
Would any of you kind people care to help an old man out and tell me if I should raise this with my provider, or accept it as the way it is.
-
Welcome to the Forum, from another Cecil! ::)
The sync rate shown by your modem is the critical thing and I think you should disregard everything else as speedtesters are often very unreliable when they are tests of TCP’s performance as they test the whole TCP system including the boxes at the two ends, not the line. The 41 Mbps speedtest you quoted is 87% of the downstream sync rate, which is a bit slow, but not unreasonable as it could be that the speedtester is a bit slow or you are using G.INP with the L2 retx system set to "high" which has quite an associated overhead, about 6% which would mean that you would expect to see IP throughput at around 91% of the sync rate. So 91% - 87 % = 4% unaccounted for, which is not outrageous. Without the L2 retx system on the "high" setting we expect to see an IP throughput downstream of around 97% of sync rate. The overhead of TCP and either IPv4 or IPv6 is either 40 bytes or 60 bytes and in a 1500 byte total length IP packet the inefficiency is then either 40/1500 (IPv4) = 2.67% or 60/1500 (IPv6) = 4%. So your speedtester results will depend on which IP protocol you use, with IPv6 being slower. Notice that that’s where your missing 4% could well be gone. So in fact we have one unproven story that would account for your numbers. However that was all guesswork as we don’t even know if you have G.INP never mind L2 retx="high". If that isn’t true then your TCP payload throughput should be about (97% - 2.67%) * sync rate (IPv4) or ( 97% - 4% ) * sync rate (IPv6).
The sync rate is what it is. Your noise levels, your crosstalk, line length and copper thickness which controls signal attenuation, all these factors affect the sync rate which, after overheads have been subtracted, as above, is the absolute limit to the speed you can get. You can’t change the sync rate much as BT won’t allow ISPs much control in FTTC systems. Putting your downstream SNRM down to 3 dB instead of your current 6 dB would speed up downloads a fair bit, but your ISP would have to tell you if that’s possible with your cabinet and with the error rate on your line, as reducing the downstream SNRM will reduce reliability.
I wouldn’t worry about it. Your speed is not fantastic but that’s just your line. Changing things like house-internal DSL wiring, having a good quality master socket and high quality lead from the master socket to your modem might make a tiny bit of difference but I’m sceptical.
My best DSL line achieves a sync rate of about 3 Mbps downstream, and 0.6 Mbps upstream. I have four copper lines combined to give me four times the speed in both directions, although for reasons unknown the upstream combined total isn’t quite * 4. So think about it, you could be me! ;D
-
New to the forums and have done lots of (very interesting!) reading about FTTC and how it all works.
Welcome to the Kitz forum. :)
I've just moved from EE to a new ISP,
Who is your new provider, please?
Currently my download speed is like this from Speedtest:
Download = 39.66 Mbps (this has been around 41Mbps over the last 24 hours)
Upload = 13.12 Mbps
. . .
Then when I check my router stats:
Upstream Downstream
Current Rate (kbps) 14156 47901
Max Rate (kbps) 14085 64083
SNR Margin (dB) 6.2 6.1
Line Attenuation (dB) 4.9 13.9
Errors (pkts) 24 0
I always look at the synchronisation speed and SNRm first of all. You have 47.9/14.2 Mbps DS/US. That tells me your new service has been provisioned on the Openreach 80/20 Mbps product. It doesn't look like banding has been applied by the DLM.
The current SNRm of 6.1/6.2 dB is the default target for a new service. Depending upon the manufacturer of the cabinet DSLAM it is possible that G.Inp could be active. If that is the case then the target SNRm could be reduced, stepwise by 1 dB over a number of days, to a minimum of 3 dB. The DLM will be checking the stability of the service and will settle on a target SNRm which is found to be the most stable. A reduction of the target SNRm to 3 dB will give an increase in the synchronisation speed.
With the limited amount of data visible, it appears that service is currently operating as well as I would expect. However let's see what other members have to say . . .
-
Thanks for the replies.
New provider is Poptelecom.
I just don't understand my speeds compared to next door. These are my neighbours stats from the bb checker website. Bear in mind he's sent me a screenshot of speed test from his mobile phone connected via wifi which had a 59MBps download speed:
Downstream Line Rate Upstream Line Rate Downstream Handback threshold
High Low High Low
VDSL Range A (Clean) 47.2 35 8.4 6.3 30
VDSL Range B (Impacted) 45.8 30 8.3 6 25
I just can't get my head round why his speeds are higher, going by these stats, compared to mine and I'm getting lower speeds.
Is it worth me buying a new router that is capable of lowering the SNR margin (again, I've read that some routers can do this, my TP-Link cannot).
-
Welcome to the Kitz forum.
How long has the line been live with Pop?
-
There are many reasons why your speed can be different from your neighbour's, such as bridge taps outside or unfiltered extensions inside your house, especially star wired ones. Crosstalk can also cause speed losses and sometimes it's just the luck of the draw that a neighbour gets a better pair of wires than you. Frustrating as that can be there is little that you can do about it. The estimates given by the Openreach checker are just that, and real life speeds can vary considerably from them.
As it's a new service I would certainly wait for a week or so to see if G.INP lowers the SNRm (assuming you are connected to a Huawei cabinet) before thinking about other possible measures.
-
Yea it's only been 3 days so I'll wait a little longer to see if anything changes.
-
Yea it's only been 3 days so I'll wait a little longer to see if anything changes.
Your snr is at 6db, if pop still use talktalk wholesale for their backhaul it may not drop to 3db.
Sky do support the 3db snr but I have no idea if pop have a 3db profile.
-
I wouldn’t even consider trying to change the SNRM using a Lantiq based router. Unfortunately comparison with neighbours is usually fruitless. Every pair is different.
-
Your snr is at 6db, if pop still use talktalk wholesale for their backhaul it may not drop to 3db.
Sky do support the 3db snr but I have no idea if pop have a 3db profile.
I'm confused - surely if the connection is via an Openreach cabinet it'll be using Openreach's DLM process irrespective of the backhaul connection?
-
I wouldn’t even consider trying to change the SNRM using a Lantiq based router. Unfortunately comparison with neighbours is usually fruitless. Every pair is different.
To add to this I have done this 3 times with lantiq based routers, to move the SNRM downwards and on all 3 occasions I got banded (quickly as well I might add), so fairly confident that is one of the triggers for DLM to band your line.
-
I'm confused - surely if the connection is via an Openreach cabinet it'll be using Openreach's DLM process irrespective of the backhaul connection?
Different carriers use different NGA profiles:
https://kitz.co.uk/adsl/DLM.htm
ISP's known to use NGA Speed Profile: AAISP, BT, Plusnet, Zen.
ISP's known to use NGA Standard Profile: EE, Sky, TalkTalk, Vodafone.
-
To add to this I have done this 3 times with lantiq based routers, to move the SNRM downwards and on all 3 occasions I got banded (quickly as well I might add), so fairly confident that is one of the triggers for DLM to band your line.
I didn't get banded doing it until my drop wire went bad, so as you'd expect it really depends on the line quality if fiddling with SNRm triggers banding or not, at least on an ISP using the Speed profile on an ECI cab anyway.
I certainly wouldn't do it until you've had the service a while to see what DLM does on its own though and probably not on a Hauwei cab as if DLM is not aiming for 3dB on its own, it has its reasons.
-
I think you didnt need to go as extreme as me to hit your target sync rate? so the extremity of the adjustment might be a factor as well, but I do think the coincidence is too much to ignore, I have only been banded 3 times, and all 3 times was shortly after I manipulated the SNRM downwards on a lantiq modem.
-
Different carriers use different NGA profiles:
https://kitz.co.uk/adsl/DLM.htm
They all use the exact same Openreach DLM.
Each NGA policy has the exact same profiles available.
Only the trigger thresholds differ.
Every single Talktalk line connected to a Huawei DSLAM is capable of a 3dB SNR target if the line is clean enough.
-
Upstream Downstream
Current Rate (kbps) 14156 47901
Max Rate (kbps) 14085 64083
SNR Margin (dB) 6.2 6.1
Line Attenuation (dB) 4.9 13.9
Errors (pkts) 24 0
The max rate being quite a lot more than the sync at 6.1 dB indicates that the line is Interleaved.
The change of ISP has likely reset the DLM and it is going through a new stabilisation period. Depending on the cab type (https://kitz.co.uk/adsl/cabinet-lookup.htm) there are still changes that can be made (such as G.inp & x.dB) which should improve your sync speed.
-
Interleaving pretty much means ECI now.
All new provisions/DLM resets on Huawei cabinets have G.INP enabled by default. There's no more waiting for it to be enabled.
Provided the modem supports it obviously.
There might be the odd one in a blue moon Huawei line with Interleaving but it's been a couple years since I've seen it.
ECI lines default to Interleaving.
-
I think DLM resets can still default to fast path, didnt kitz mentined before was two types of reset?
AAISP requested a reset on my line last week and it removed the banding but stayed on fast path, engineer did another reset today, and its still fast path. I was actually hoping for interleaving.
-
There were indeed two different types of DLM reset.
A hard reset that completely clears any profiles and the line enters an open profile without any DLM restrictions including interleaving, g.inp or banding. Within 24hrs it then goes to default of interleaving, then g.inp for the Huaweis and FAST for the ECI's (if stable). The soft reset (usually) doesnt clear any banding and g.inp for Huawei.
Any requests for reset that are ISP or BTw or Openreach OSS are a soft reset. A hard reset can be performed by an Openreach engineer - the idea being he can test the line and check line performance without any DLM configs such as interleaving which may mask a fault. It will only remain open profile for the remainder of the day, or will apply interleaving if the line is really bad by triggering "Scarlet".
I was under the impression that all new provisions (which can include ISP change) went through the Open profile, however I am not up to date with whats happening atm and you are in a far better position than me when it comes to whats happening in the real world right now and I bow to your observations.
I just noticed the max rate discrepancy indicating the line is probably interleaved ... and the possibility of a better line rate if the line is stable. :fingers:
-
Thanks for that info kitz, so thinking on what you described perhaps if my line was interleaved the AAISP soft reset would not have cleared it, it just merely kept what was there, but did remove the banding.
Then engineer did a hard reset, which makes it open profile and because errors were low it stayed on fast path. If I understand you right that is perhaps what happened.
-
There were indeed two different types of DLM reset.
A hard reset that completely clears any profiles and the line enters an open profile without any DLM restrictions including interleaving, g.inp or banding. Within 24hrs it then goes to default of interleaving, then g.inp for the Huaweis and FAST for the ECI's (if stable). The soft reset (usually) doesnt clear any banding and g.inp for Huawei.
That was indeed the case from the initial G.INP rollout.
Openreach must have resolved the issue of the DLM having to work out if a modem supported G.INP or they now just don't care about modems that don't support it.
Huawei lines now start with G.INP and retain it on a DLM reset or migration.
That only changed a couple years ago after an initial trial then an extended trial.
This briefing is to inform CPs that we'll be deploying a change to apply ReTransmission to lines on day 0 where supported.
Dynamic Line Management-ReTransmission on day 0
(https://www.openreach.co.uk/cpportal/updates/briefings/superfast/nga01920)
I was under the impression that all new provisions (which can include ISP change) went through the Open profile, however I am not up to date with whats happening atm and you are in a far better position than me when it comes to whats happening in the real world right now and I bow to your observations.
Interleaving is definitely the default on ECI lines for new provisions.
That started in Feb 2018 for some tiers and was extended to the 80/20 package in August 2018.
https://www.ispreview.co.uk/index.php/2018/08/openreach-extend-low-level-error-correction-to-new-80mbps-fttc-lines.html
DLM resets are a bit of a dark art now, which I assume includes some migrations.
Provider initiated resets usually keep the current profile while engineer resets tend to put lines on interleaved. That's clearly not always the case though, as seen from Chrysalis' line.
I've never understood the whole hard reset/soft reset thing either or how some engineer resets have different outcomes to other engineer resets.
There have been no recent changes to the DLM this year but in 2020/21 Openreach put out a lot of DLM related briefings with lots of trials and changes.
They made changes to the "Standard" DLM policy, they held trials on retaining the current DLM profile for product moves, introduced Retx on day 0, added/trialled a new stability policy, trialled MTBR changes, trialled higher levels of Retx and started/stopped half a dozen ISP DLM reset schemes.
If you can keep up with all that you're doing better than me :D
Nothing regarding G.INP on ECI for a long time either.
I don't think that's ever going to happen now.
-
I thought G.INP already sorted out on ECI cabinets by now? Has Openreach giving up now because of rolling out FTTP.
-
I thought G.INP already sorted out on ECI cabinets by now?
No, it has not been resolved. ECI hardware in the Openreach access network has, basically, become a bit of an embarrassment. ::)
Has Openreach giving up now because of rolling out FTTP.
Your guess is as good as mine. ;)
-
Oh dear me poor all of those have to suffers with crappy ECI cabinets. Never understand why Openreach installed more Huawei cabinets than ECI cabinets. Should have 100% of all Huawei cabinets.
I guessed I am very very lucky indeed to have my healthy FTTC line with the closer distance to the Huawei cabinet. Still on stable 80/20 for 5 months now since migrated from G.fast to FTTC. ;)
Anyway everyone can look forward to FTTP soon. :fingers:
-
Thanks j0hn for all the additional info appreciated.
As an aside I was looking at the new SIN 498 dated Nov 2022 for something else and happened to spot this. :-[
"At provision, the line is put on "wide open". VDSL2 line profiles allowing the upstream and downstream line speeds to run at the upper limit of the product option selected.
On the first day of operation, DLM will intervene if severe instability is detected. Otherwsie DLM will wait until the day after provision before deciding ......
I know its been like that for a while, but you'd think they would update it if its no longer true :/
-
Oh dear me poor all of those have to suffers with crappy ECI cabinets. Never understand why Openreach installed more Huawei cabinets than ECI cabinets. Should have 100% of all Huawei cabinets.
They used both because it could have just as easily been Huawei that had the problem, so by having two vendors it was unlikely a problem would happen on both, so they had a backup solution.
Its also a way to avoid supply issues or issues like the government deciding Huawei aren't trustworthy. If you put all your eggs in one basket, these problems can be far more costly. Plus the sheer scale they were rolling out cabinets, one supplier likely could not have supplied enough hardware to work that fast.
The ECI situation sucks, but by the time the scope of the problem was identified, it was too late to do anything about it and it could have been much worse. ECI were probably promising a firmware fix for years before realising it wasn't possible.
eg When I was on Digital Region their line cards topped out at 60Mbit due to a hardware issue and they had to swap out the entire card to unlock the full 100Mbit. One of many issues they had due to going with a one-supplier solution.
-
@ Max
As Alex says, they've always used at least 2 different suppliers - theres several different MSANs and the old adsl DSLAMs. For FTTC, at one time the ECI's were considered superior & more advanced than Huawei. It's only really when g.inp rolled out that the problems started occurring. I#m still not convinced the g.inp problems are entirely ECI, but rather certain modems dont play nice with ECI g.inp. Some of the modems we saw potential issues with were the BT HomeHub 5A, Openreach ECI modem and Draytech Vigor 2850 series. When g.inp first rolled out a high proportion of users had the first 2 of those modems :(
One of the ECI M41's selling points was the small cab size which at the time could hold as many lines than the substantially larger Huawei MA5603T. Unfortunately the small size was problematic because there wasnt enough room inside to add a vectoring module. ECI led the way with vectoring but for this you needed the ECI E41. I dont think the E41's were in general production when Openreach pre-ordered thousands of the M41's which they began installing in 2012. There were a few other ISPs who had ECI cabs - for example Deutsche Telekom. I believe they swapped out some of their M41s for E41s or replaced with other kit.
In the grand scheme of things the lack of g.inp on the ECI's probably isn't that great. The average user wouldnt have a clue that the Huawei cabs have full g.inp. They probably don't even know their sync speed and don't care that users on a different cab are now able to get better error protection. It doesnt make a vast difference to sync.... the main advantage is g.inp v interleaving so potential for better latency. However that's a moot point when you have gamers using wifi to hook up their console. :no:
-
Some of the modems we saw potential issues with were the BT HomeHub 5A, Openreach ECI modem and Draytech Vigor 2850 series. When g.inp first rolled out a high proportion of users had the first 2 of those modems :(
Plus AFAIK at least the first two were fixed with modem firmware updates, as used both on G.INP myself on OpenWRT. I mean not sure I needed G.INP once my drop wire was replaced, but it was stable, so stable I didn't realise the drop wire was damaged until it failed completely which would suggest it was doing its job.
-
As an aside I was looking at the new SIN 498 dated Nov 2022 for something else and happened to spot this. :-[
I know its been like that for a while, but you'd think they would update it if its no longer true :/
I did noticed that. From G.fast changed over to SoGEA 80/20 last June my isp thought it will be a few days later for G.INP and INP to be applied on the downstream but it went straight away 80/20 with G.INP enabled with INP of 48 with interleave dept of 16 from minute of activated and remain there the same for nearly 124 days now with no change.
Stats recorded 23 Nov 2022 16:21:06
DSLAM type / SW version: BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware: AnnexA version - A2pvfbH043q.d26u
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 123 days 18 hours 47 min 26 sec
Resyncs: 0 (since 23 Nov 2022 16:19:05)
Downstream Upstream
Line attenuation (dB): 12.2 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 79999 20000
SNR margin (dB): 7.6 10.7
Power (dBm): 12.5 -0.2
Interleave depth: 16 1
INP: 48.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0009 0.0000
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
Since Link time = 123 days 18 hours 49 min 56 sec
FEC: 20606 0
CRC: 3 6064
ES: 2 5278
SES: 0 1
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
HostInitRetr: 0
FastRetr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
ZySH>