Any advantage to FTTC with LLU supplier?

Hi,

I've experienced progressive speed reductions on my FTTC connection over the last couple of months. My sync used to be a solid 56Mbps with 6dB SNRM and minimal errors but at the end of February the SNRM dropped to 3dB. The 56Mbps sync wasn't affected until three weeks later when I lost connection and had to reboot at the lower rate of 48Mbps.

The following day throughput had dropped to 9Mbps downstream and 0.12Mbps upstream so an engineer was sent. He reset the connection but the sync was lower still at 38Mbps with 6dB SNRM, sadly above the BT line speed estimate of 35Mbps. Several DLM-sensitive reboots later I was stuck on an exact 40,000Kbps sync despite there being no banding or cap.

A subsequent GEA test found an impaired junction but the engineer sent to fix that made no measurable difference. The next engineer checked the line back to the cabinet and determined that there was an AC imbalance on the dropwire. He changed the last 50m or so of overhead cable and downstream attenuation improved slightly from 26.2dB to 25.9dB but sync was back to 38Mbps again. After a couple of days there was a network initiated resync as G.INP was re-applied and I'm now on 44.7Mbps, so around 11.3Mbps down on what used to be normal.

There's now nothing apparently wrong with the line and I live in a rural area so have my doubts about the possibility of hordes of new users all coming online at the same time and eating up bandwidth. If the slowdown had been more progressive I'd have accepted the contention argument but I feel that there were sudden changes. Having tried three different routers and given DLM ample time to settle I've run out of options.

Maybe DLM isn't working as intended or has gained sentience and taken an arbitrary dislike to me. When I was on ADSL broadband with an LLU supplier it was a great relief to be free of BT profiles and over protective DLM which would limit me to painfully slow speeds for three days if offended. There are two LLU suppliers listed for my exchange but it's not clear whether they just provide a slightly more independent ADSL service or an FTTC connection which might let me have whatever speed the line is capable of without profiles and aggressive DLM. I don't want to switch to Talktalk and find that they are just reselling the BT product.

Edited by deleted (Sun 12-Jun-16 19:35:09)

DLM applies to all sellers of the FTTC service.

If the line is better the DLM will relent but it can take some weeks

Could be crosstalk. That's when the signals carried on a line 'leak' into other nearby lines. It's a known problem that particularly affects FTTC. It doesn't require significant numbers of users on a cabinet. It only requires that your telephone line run close to another line carrying FTTC.

The odds of that happening do increase as the cabinet provides service to more and more people but you could just be unlucky. Even with only two subscribers if their lines run close enough together for long enough they could both experience crosstalk interference. Conversely if your line happens to be at the edge of a bundle you could escape crosstalk effects even if your cabinet was fully subscribed.

The longer your line the more likely it is to pick up interference but any line can be affected. Pretty much all FTTC subscribers will be affected by it eventually to some extent but how soon and how badly is pretty much pot luck.

Edited by Andrue (Sun 12-Jun-16 20:17:46)

Reading your last couple of paragraphs, you seem to be blaming DLM. Is there a reason for this? That can be seen in detailed stats?

If you have G.INP activated downstream, and you aren't banded, then DLM is essentially as de-intervened as you could hope for.

A speed of 44.7 doesn't sound like a banded one. What value precisely? What is the SNRM just after a resync? Something very close to 6dB suggests no banding.

The rise in speed when retransmission activated, of 10%+ suggests that it took away old-style FEC+interleaving, but it is impossible to tell whether that was originally triggered by the faulty line, or just an increase in the error rate that tends to come along with increased crosstalk. Yes, crosstalk can happen in both big and small jumps, but if it pushes you over the (old-style) error threshold, you'd suffer the double-whammy of FEC grabbing an extra 10%+ of your speed.

Does your modem give you detailed error stats?

Thanks, I'll stay with my current ISP and try to restrain my itchy fingers from clicking the restart link for at least a month

In reply to a post by Andrue:

Could be crosstalk. That's when the signals carried on a line 'leak' into other nearby lines. It's a known problem that particularly affects FTTC. It doesn't require significant numbers of users on a cabinet. It only requires that your telephone line run close to another line carrying FTTC.

You may be right. Is there any test for that or is it something which is assumed if other tests don't find a specific fault?

In reply to a post by WWWombat:

The rise in speed when retransmission activated, of 10%+ suggests that it took away old-style FEC+interleaving, but it is impossible to tell whether that was originally triggered by the faulty line, or just an increase in the error rate that tends to come along with increased crosstalk. Yes, crosstalk can happen in both big and small jumps, but if it pushes you over the (old-style) error threshold, you'd suffer the double-whammy of FEC grabbing an extra 10%+ of your speed.

Does your modem give you detailed error stats?

I use DSLStats v5.8 . It's only been 37 hours since the last reboot so the data sample is small but here's an extract:

Total time = 1 days 13 hours 5 min 22 sec
FEC: 2410424 0
CRC: 0 337
ES: 0 239
SES: 0 5
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 5 min 22 sec
FEC: 2809 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 28275 0
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0


Upstream seems to be getting the worst of CRC and SES errors and downstream the FEC. Current sync is 44.676Mbps and SNRM is 5.8dB. It seems a bit more volatile these days but only over a very small range, being briefly 6.5dB this morning

Edited by deleted (Sun 12-Jun-16 22:54:09)

There are 3 DLM stability options available to all ISP's most are known to choose the Openreach SPEED option , as default , but some choose other options, which may or may not may a detrimental difference to the sync speeds experienced due to the error rate thresholds being different between the 3 stability options,

The only other advantage / disadvantage between llu suppliers and BT Wholesale is that llu operators don't use the same network for back haul, and there is no BTW IP profile with BT Openreach GEA (LLU) services , so if you are close to the FTTC cab then you may see a slight increase in throughput if compared to a connection using BTW as the IP profile does take a small amount of potential throughput away from the EU

Apart from that possibly support standards but they are ISP specific and not LLU or BT ,

In reply to a post by tommy45:

... and there is no BTW IP profile with BT Openreach GEA (LLU) services , so if you are close to the FTTC cab then you may see a slight increase in throughput if compared to a connection using BTW as the IP profile does take a small amount of potential throughput away from the EU.

Slightly misleading there Tommy . There is no difference in GEA between BT Wholesale based ISPs and what are (at the exchange) LLU ISPs. There is no such thing as Openreach GEA (LLU). The data is simply handed over to or received from BTW or Sky/TT/Vodafone/Zen at the exchange and all treated the same from there to the user.

The loss on BT Wholesale is typically less than 3.4%, (most frequently 3.21% without G.INP and 3.31% with G.INP), of the theoretical throughput if there wasn't a transmission protocol in place. But there has to be. That below 3.4%,basically accounts for the overheads inherent in packaging the data for VDSL2 so ISPs know how much to send without losing packets at the modem.

ADSL2+ LLU suppliers have to have some figure within their own systems that do something very much like the IP Profile, else they would be dropping packets by the bucket-load at their MSANs when transmitting. They have to buffer it is some way, just like BTW does.

The same principle applies on GEA. A technical description can be found at SIN 498v7.1 Section 1.2.1. (Note for anyone reading in the future, google SIN498, as the version number updates quite frequently).

I agree that Sky and TalkTalk can often give slightly higher speeds than BT Wholesale based, but just blaming the IP Profile is over-simplistic. They too have a loss, not no loss.

Broadly, that's a huge rate of FECs downstream, but a very low level of CRC and ES. It means that you are suffering from a fair amount of noise, but it isbeing dealt with successfully.

The FEC process (much reduced when retransmission is active) is catching a lot of the flak. Unfortunately, these figures don't capture the behaviour of retransmission, so we don't see how much FEC is missing. But, because CRC is low, we know that little fails retransmission.

What we can probably guess is that your line suffered a lot of noise before, and (prior to G.INP), your line likely needed higher grade DLM intervention. Likewise when things were bad enough to drop speeds to 9/0.1.

If your line really did suffer few errors, then that has changed. Perhaps your old DSLstats graphs can tell you whether this came on gradually or suddenly.

In reply to a post by RobertoS:

In reply to a post by tommy45:

... and there is no BTW IP profile with BT Openreach GEA (LLU) services , so if you are close to the FTTC cab then you may see a slight increase in throughput if compared to a connection using BTW as the IP profile does take a small amount of potential throughput away from the EU.

Slightly misleading there Tommy . There is no difference in GEA between BT Wholesale based ISPs and what are (at the exchange) LLU ISPs. There is no such thing as Openreach GEA (LLU). The data is simply handed over to or received from BTW or Sky/TT/Vodafone/Zen at the exchange and all treated the same from there to the user.

The loss on BT Wholesale is typically less than 3.4%, (most frequently 3.21% without G.INP and 3.31% with G.INP), of the theoretical throughput if there wasn't a transmission protocol in place. But there has to be. That below 3.4%,basically accounts for the overheads inherent in packaging the data for VDSL2 so ISPs know how much to send without losing packets at the modem.

ADSL2+ LLU suppliers have to have some figure within their own systems that do something very much like the IP Profile, else they would be dropping packets by the bucket-load at their MSANs when transmitting. They have to buffer it is some way, just like BTW does.

The same principle applies on GEA. A technical description can be found at SIN 498v7.1 Section 1.2.1. (Note for anyone reading in the future, google SIN498, as the version number updates quite frequently).

I agree that Sky and TalkTalk can often give slightly higher speeds than BT Wholesale based, but just blaming the IP Profile is over-simplistic. They too have a loss, not no loss.

Openreach GEA does exist and it's what LLU providers use as opposed to BTW, The LLU in brackets was meant as a reference to what LLU operator use , and not a open reach product , and openreach GEA doesn't use the same Bras IP profile system , i didn't say that it isn't managed in some way, but from published speed test results throughput seems to be a little higher than BTW based customers see (80/20 sync rates)

Of course Openreach GEA exists, but the way you wrote the post is that there is a variant of it provided for LLU suppliers. First, as I said, there is no such variant, and second (which I didn't say) technically there is no such thing as LLU FTTC anyway. You made a technical post and it was not quite accurate for the reader. To one who already knew how it worked it was obvious what you meant. To one who didn't already know, I thought it possibly misleading. It was also just possible you didn't fully understand how it works either causing you to write it the way you did.

GEA is Openreach's product designed to fulfil the requirements of Ofcom VULA. How it works is identical for BTW and non-BTW. The overview here gives a basic explanation of the difference between LLU and VULA. It is only at the exchange GEA is handed over to CPs (Communications Providers) who apply their own systems to adhere to the requirements of SIN 498. In BTW's case, their IP Profile system.

Furthermore, Openreach doesn't just not "use the same BRAS IP Profile system", it doesn't use/have one at all.

Note I began my previous post with "Slightly misleading". I didn't say you were wrong, but just tried to clarify things for the OP, without writing all this stuff which wasn't necessary at the time.

Re the throughput speed, at the end of my previous post I agreed with you. You didn't need to repeat it .

In reply to a post by WWWombat:

Broadly, that's a huge rate of FECs downstream, but a very low level of CRC and ES. It means that you are suffering from a fair amount of noise, but it isbeing dealt with successfully.

I've only been using DSLstats fora few weeks but always have Routerstats running and that's how I noticed the overnight switch from an SNRM which occasionally moved a tenth or two either side of 6dB to a flat 3dB. At that time I relied on the stats reported by my Billion 8800NL's UI (which don't include FEC) and there was nothing out of the ordinary.

With a sync of 56.122Mbps which had held for over two months at that point I was still seeing a gnat's under 52Mbps downstream and 6.5Mbps upstream on speed tests. That remained the case for the next three weeks until I was forced to reboot the router. I don't remember the exact figure but with the new 48Mbps sync the downstream throughput was around 45Mbps. A day later the sync hadn't changed but throughput had dropped to 9/0.12 .

Even with a 20.4% loss of sync speed my connection is about seven times faster than it was six months ago with ADSL2+ so I'll just leave the router alone and hope that Vectoring which was pencilled in for 'the summer' may help a little.

In reply to a post by tommy45:

In reply to a post by RobertoS:

I agree that Sky and TalkTalk can often give slightly higher speeds than BT Wholesale based, but just blaming the IP Profile is over-simplistic. They too have a loss, not no loss.

Openreach GEA does exist and it's what LLU providers use as opposed to BTW, The LLU in brackets was meant as a reference to what LLU operator use , and not a open reach product , and openreach GEA doesn't use the same Bras IP profile system , i didn't say that it isn't managed in some way, but from published speed test results throughput seems to be a little higher than BTW based customers see (80/20 sync rates)

FWIW I 've been trying to work out overheads recently, I don't know if I'm totally right, but seem to be very close testing my 20meg sync upstream.

Ignoring profiles totally, for someone with an 80meg sync I recon tcp data rate should be 413 kbit better for TT/sky vs BTW ISPs just because of using ipoe vs pppoe.

FYI TalkTalk also use PPPoE authentication on FTTC. On a sync of 80/20 on TalkTalk ive never had speeds greater than 75.10 on speed tests (wired).

In reply to a post by baby_frogmella:

FYI TalkTalk also use PPPoE authentication on FTTC. On a sync of 80/20 on TalkTalk ive never had speeds greater than 75.10 on speed tests (wired).

Oh, OK I was going by a quick search which comes up with recent TT forum threads on own router setup that claim ipoe, eg.

http://talktalkmembers.com/t5/Superpowered-Fibre-Bro...

FWIW 75.10 tcp data is a bit higher than my calculated value for pppoe - but then I know many speed testers can over report.

Edit - You said also, so does that mean you can choose?

Edited by deleted (Mon 13-Jun-16 12:48:13)

In reply to a post by spinynorman:

You may be right. Is there any test for that or is it something which is assumed if other tests don't find a specific fault?

I believe that some BT engineers carry equipment that can detect it but for the rest of us it's a guess when there's no other obvious cause

In reply to a post by spinynorman:

You may be right. Is there any test for that or is it something which is assumed if other tests don't find a specific fault?

Some modems give you access to the QLN data, quiet line, which shows the amount of noise the modem could hear on the line prior to the most recent sync. As such, it only changes when there is a new sync.

When crosstalk increases noise by around 3dB, the sync speed might drop by around 15% (around 11Mbps on a line around 70-80Mbps).

It doesn't matter how many or few steps are needed in the accumulation of crosstalk, how many or few months. Eventually, something like a 3dB increase in noise ought to be visible in the QLN graphs.

Hard to "test" for in a one-off test, but visible in graphs collected by stats apps over time.

there is a possible advantage but not related to DLM, the advantage would only be if for some reason your service suffers from backhaul issues in which a LLU provider can bypass.

In terms of the cabinet to socket part of the service, that is all openreach only regardless of the provider, the only variable between different providers might be the DLM profile used.

In reply to a post by WWWombat:

In reply to a post by spinynorman:

You may be right. Is there any test for that or is it something which is assumed if other tests don't find a specific fault?

Some modems give you access to the QLN data, quiet line, which shows the amount of noise the modem could hear on the line prior to the most recent sync. As such, it only changes when there is a new sync.

DSLstats shows me a QLN dBm/Hz vs Tone number graph. I've made a copy and will compare after the next sync. Most of the currently available data shows the majority of activity in the -140 to -130 range but Tone numbers 30 to 61 show from -127 to a peak of -112 and there's a lot of instability between Tone numbers 160 to 374.

[IMG]http://i103.photobucket.com/albums/m142/pb291/QLN_zp...[/IMG]"]QLN graph

In reply to a post by Chrysalis:

In terms of the cabinet to socket part of the service, that is all openreach only regardless of the provider, the only variable between different providers might be the DLM profile used.

I'll probably stay with my current ISP for now as my only viable LLU provider is TalkTalk who have a speed estimate for my line of 11 to 27Mbps with a minimum service guarantee of 9Mbps, based on the BT 'impacted line' figures.

The estimates are irrelevant as far as line performance is concerned once we know the actuals. As long as those actuals are fault-free and home wiring is optimised.

If someone is getting 60Mbps with ISP A and ISP B estimates maximum 52Mbps (for the 80/20 OR product) then the actual with ISP B will be around 60Mbps. The variance depending mainly on the stability settings they request and the protocol used.

That's all very well when the connection is working normally but ISPs tend to rely on the estimated speed when it comes to accepting faults.

Initially my current ISP wouldn't let me have their 80/20 product based on their use of the upper clean line figure, in my case 35Mbps. I'm about 500m from the cabinet. I started with their 40/2 product with a sync close to 50Mbps and a throughput of nearly 38Mbps as a result of capping. I was lucky enough to find a sympathetic tech support guy who offered to put me on the 80/20 product as a trial. It worked fine for me and sync settled to a stable 56Mbps.

When my SNRM dropped overnight from 6dB to 3dB and three weeks later a reboot dropped the sync to 48Mbps I was told that they wouldn't be able to pass it to Openreach as a fault because I was still way above the upper estimate of 35Mbps. By chance, the following day saw throughput drop to 9Mbps/0.12Mbps (sync still 48Mbps) and a fault was raised. That in itself was lucky according to yet another tech support guy as it's the sync speed they are trained to go on and not throughput.

Subsequent attempts to have the connection checked have varied in success between those techies who interpret their training to the letter and those more sympathetic. I wouldn't feel confident with an ISP lowering the fault threshold bar to 27Mbps.

Edited by deleted (Tue 14-Jun-16 12:53:38)

That's a totally different topic from what I was talking about in my post, which was a reply to your implied thoughts that TalkTalk might only let you sync at 27MBps in the first place.

In reply to a post by spinynorman:

I've made a copy and will compare after the next sync.

That is why grabbing the stats from the first day of connection is worthwhile: it gives you the data to look back on too.

You probably need to use the "compress/expand" scrollbar to get the rest of the data. You're missing the information from the other 3,400 tones.

In reply to a post by WWWombat:

You probably need to use the "compress/expand" scrollbar to get the rest of the data. You're missing the information from the other 3,400 tones.

I'm going to need a *much* bigger monitor

[IMG]http://i103.photobucket.com/albums/m142/pb291/QLN_zp...[/IMG]

Edited by deleted (Tue 14-Jun-16 22:27:05)

In reply to a post by legume:

FWIW 75.10 tcp data is a bit higher than my calculated value for pppoe - but then I know many speed testers can over report.

Maybe I should retract that as I can't test 80 meg down my self and making some assumptions (no fcs) it could be possible and examples in openerach docs only work out assuming no fcs (the dsl specs don't say either way).

Trying to work out overheads by testing upload seems to depend on which modem I use. My locked ECI seems to send fcs (or it throttles a bit to make me believe that).

Tried an unlocked Huawei yesterday and it's consistently 20kbit tcp throughput slower than the ECI so it must be doing something different. It's not the QOS - that's off and would cost much more than that. Maybe because I used the latest G.inp firmware or maybe not, I don't think it's actually using using G.inp. I guess I should try older firmware sometime, but having never seen stats for my line till yesterday I'll leave it running for a while.