Line Errors

Hi all,

Currently still battling with Openreach with regards to line speeds.

Had yet another chap turn up yesterday to look into it and, whilst speeds have increased slightly, there still appears to be errors on the line after around 24 hours.


Downstream Upstream
Actual Rate 58924 Kbps 15877 Kbps
Attainable Rate 58472 Kbps 15978 Kbps
Path Mode Fast Fast
Interleave Depth 1 1
Actual PSD 6. 7 dB 6. 9 dB
Near End Far End
Trellis ON ON
Bitswap ON ON
ReTx 0 0
SNR Margin 5 dB 6 dB
Attenuation 19 dB 24 dB
CRC 12430 211
FECS 168380 s 12686 s
ES 799 s 51 s
SES 0 s 0 s

AM i worrying over nothing?

There is nothing at all connected to the line, except the router, so have ruled out dodgy phones etc.

Thanks

What errors are you worried about?

The ES figure is the only important 1 that the DLM is interested in.

Your line had zero error protection (no G.INP and no Interleaving) so a decent amount of ES is expected.

The 24 hour limit for ES is either 1440 or 2880 depending on the ISP.

Perfectly normal level of errors in other words.

Ok great, thanks John.

As an update to this, turns out our home phone may have been causing the problems (according to engineer).

Anyway, unplugged and binned the old phone and ordered a new one.

In the meantime, over the day or so it took to deliver, the errors were very low, however, i plugged the new phone in this morning and the errors have shot up again.

This is a brand new panasonic cordless phone, using all the new cables etc.

Could there be a problem with the new filter fitted?

Its one of the new 5c ones.

Thanks

Have you a dangly filter you could plug in to the test socket?

In reply to a post by Alucidnation:

There is nothing at all connected to the line, except the router, so have ruled out dodgy phones etc.

Hi Alucidnation, I for one am confused as you initially posted above and now you've posted below.

In reply to a post by Alucidnation:

turns out our home phone may have been causing the problems

Sorry guys, i kinda worded it a bit wrong.

The engineer blamed the phone.

After he left, it turned out the phone was still plugged back in (hence the high errors) as its plugged in behind a cabinet and not easy to see.

The readings in the OP were after i discovered the phone was plugged in so i removed it took a screenshot and rebooted the router.

I ordered a new phone that arrived yesterday (errors were minimal), and this morning plugged it in and they shot up again.

These are after it was plugged in for less than a minute.


CRC: 50
FECS: 741
ES: 45

Now, 9 hours later..

CRC: 1022
FECS: 20053
ES: 863.

Also, My attainable rate has dropped from 58997 to 58642 ( for reference).

Just seems odd that having a phone plugged in, and not being used would cause any errors at all.




I do have one of the [censored] dangly filters so i could try that in the test socket.

Its always best to try a phone via a microfilter in the test socket as that will eliminate the faceplate and any internal wiring (if you have it).

Your old and new phones are they mains powered? it may seem a strange question but I have seen it when the mains feed wasn't clean and it has caused line interference although I realise its a long shot in your case.

Thanks ill give the dangly filter a go as i have three of them for some reason.

And yes, they are/were both mains powered, albeit plugged in a different socket but on the same circuit.

No internal wiring, so the OR pair come straight in to the back of the 5C.

The second engineer that came ripped out the MK4 filter plate and put the new one on before he did anything, so it might be the new filter.

Odd thing is, inbetween two of the many visits, the old phone was plugged in but registered very few errors, but that was when my sync speeds were way down.

Common problem with some DECT phones.

Double filtering has been known to help. In other words plug a dangly filter in to the the filtered faceplate, and connect the DECT phone to that and see if the errors go away.

Not the best looking outcome but simple if it works.

If you suspect a phone handset you should test to eliminate that by using something like this.

(It's also handy to have something like that as you would still have a working phone in the event of a power cut)

Edited by jelv (Wed 16-Jan-19 00:08:15)

@john,

Thanks John, will give that a try, although we have had a DECT phone plugged in for years with no effect on speeds AFAIK.

@jelv,

Funny you should suggest that, as i bought one from eBay last night.




Over a 24 hour period, the errors are now at...


CRC: 119113
FECS: 1884262
ES: 5405

Just getting a bit concerned DLM might rear its head soon.

Edited by Alucidnation (Wed 16-Jan-19 06:52:08)

As an update, plugged in another filter so that the phone was double filtered and this seemed to make no difference at all.

After about an hour it was racking up errors so i unplugged the new phone from the phone socket and left it all day and checking the stats when i got home around 4, there were barely any errors registered at all.

Let us know if DLM does take any action as with 5000+ ES in 24 hours it is very likely the line could have interleaving enabled.

It's a shame the double filtering has no effect as this has worked in the past.

Interleaving applied last night.

I obviously wasn't quick enough with unplugging the phone.

Limit is either 1440 or 2880 ES in 24 hours.
Which 1 depends on the ISP.
Safe to say you smashed that.

The line now needs stability and multiple concurrent days with low ES before it will return to fastpath.
If fastpath is important to you (eg gaming) then you should put the phone testing on hold.

Your old handset had 799 ES in over 24 hours which is perfectly fine for fastpath. Was that also a DECT phone?

Yes it was, around 5-6 years old.

Since interleaving was applied this morning around 3am, i have no ES errors at all for the last 10 hours.

Actual sync speed has dropped from 58ish to 52, with a now obtainable of 60.

Still no phone plugged in.

After leaving phone unplugged for a while, i had no es errors and a few FECS errors.

I plugged the standard 'wired' phone in for a couple of hours and also, no ES errors.


With that i plugged back in the new DECT phone just to have a quick look and so far, still no ES errors however FECS errors have shot through the roof!

I will unplug the new phone later, but will interleaving suppress any ES errors that would be likely to occur?

Do FECS errors get monitored by DLM?

Thanks guys.

Edited by Alucidnation (Fri 18-Jan-19 17:08:16)

Yes, interleaving/INP is set to use FEC (Forward Error Correction).
Those FEC's are errors that have been corrected, preventing ES.

In my experience DLM won't return the line to fastpath with excessive numbers of FEC.

There are particular brands of DECT phones that play well with FTTC and others that don't. It's not my area, I don't have a landline connected at all.
No idea if you are able to return the new DECT phone you bought but the line won't hold fastpath with it, if that's important to you.

Low Interleaving adds 8ms delay and knocks (very roughly) 10% off the sync compared to fastpath.

If you don't mind 8ms latency and a few Mb off the sync then interleaving can be a bit more stable with less packet loss.

What's your sync now, 53-54Mb?

Edited by j0hn83 (Sat 19-Jan-19 02:27:01)

Hi John,

Thanks for the detailed explanation.

Yes, at the moment i am syncing at around 52 with an attainable of around 60.

I have just unplugged the DECT phone after 10 hours and FECS have risen to 338578860, whilst ES are at 49, and CRC 50.

The only reason for wanting a portable phone, is that the phone line enters the house from underground in the lounge and it's position is tricky to have comfortable phone conversations in it's current location.

Yes, fast path is reasonably important as the kids do a fair bit of gaming.

Thanks again.

Edited by Alucidnation (Sat 19-Jan-19 07:18:01)

It sounds like straw grabbing, but have you tried a different make of cordless phone ?

I can vaguely remember years ago having an issue with an ADSL line, which was due to a Panasonic cordless phone ( the biggest issue being that the line in question was in a Panasonic shop, so they wouldn�t try something else)

There was mention elsewhere of �double filtering� the phone, did you try that ?

Hi,

Funnily enough, the new phone is a Panasonic!


Yes, i did try the double filtering but made no difference.

The previous phone was a Siemens Gigaset which admittedly, is the one we were using for a few years with no apparent problems.

I am going to return the Panasonic, so maybe ill try another Gigaset.

I thought you�d mentioned it was a Panasonic elsewhere ...

I hope this change sorts it, and keep up the commentary.

Well, that was short lived.

Just plugged in the Gigaset and whilst CRC and ES are the same, FECS again took a massive jump, after being relatively stable after a few days.

As of around 8am today they were at 338583224.

Before plugging the new phone in at 12.40pm they were 338584269.

Phone been plugged in for 10 minutes and they have jumped to 340307809!

Thats just over 1.7M in 10 minutes, 172,000 per minute and 2872 per second!

I just don't get it.

As i said before, we had a Gigaset phone for years without it affecting our speeds/internet etc.

Something has got to be wrong somewhere!

Edited by Alucidnation (Sun 20-Jan-19 12:57:16)

Hi Alucidnation

Is it worth you summaries everything you have tried and what was the results as you have now tried several scenarios and not sure if results were consistent with each attempt.

Ok, i'm out and about at the moment so i'll give it a go this eve.

Righto, in that case, my guess is that you have a very minor HR fault somewhere .....

Funnily enough, i have been reading up on FEC errors and a couple of people have had similar.

I have reported this to my ISP and they suggested another engineer visit which they have arranged for tomorrow morning.

As of now FECS are at 341393522 from 340307809, and that is with the phone unplugged after my post at 12.55pm, and that's just over 1M in just over four hours.

One thing i have noticed is the face plate of the new 5C filter is not all that firm as when i plug in and out it has some movement.

I haven't taken that off and tried the test socket as i didn't want to keep resetting the modem error stats.

Edited by Alucidnation (Sun 20-Jan-19 17:11:02)

When the next bod comes to do an SFI, ask them to put their tester into manual sync, then plug their butt in at the same time whilst watching the error counter ....

It might be the only evidence they can chase.

Maybe wacking the gain up on the TDR might show something.

If they start saying �but the PQ test passes� maybe politely suggest they check with their senior engineer...... many HR faults don�t show up on a PQ test.

In reply to a post by Zarjaz:

When the next bod comes to do an SFI, ask them to put their tester into manual sync, then plug their butt in at the same time whilst watching the error counter ....

It might be the only evidence they can chase.

Maybe wacking the gain up on the TDR might show something.

If they start saying �but the PQ test passes� maybe politely suggest they check with their senior engineer...... many HR faults don�t show up on a PQ test.

Am i reading this correctly?


But anyway, thanks for the advice!

In reply to a post by Alucidnation:

In reply to a post by Zarjaz:

When the next bod comes to do an SFI, ask them to put their tester into manual sync, then plug their butt in at the same time whilst watching the error counter ....

It might be the only evidence they can chase.

Maybe wacking the gain up on the TDR might show something.

If they start saying �but the PQ test passes� maybe politely suggest they check with their senior engineer...... many HR faults don�t show up on a PQ test.

Am i reading this correctly?


But anyway, thanks for the advice!

A but in openreach speak is a test telephone handset, in fact the terminology goes back to the Post Office Telephone days, I know cos I worked for them back in that era, long since retired

Ah ok thanks.

Anyway, quick update.

Re -sync this morning just before seven so im now on fast path.

Error stats were automatically reset so with that, plugged the new phone in.

In just under an hour with the phone in, i have accumulated...

CRC: 3360
FECS: 248623
ES: 1755


I am guessing the engineer reset DLM, as this happened before when i was interleaved with an engineer appoint booked for that day.

I have unplugged the phone again for now.

I strongly advise you don't connect that DECT phone again if you like fastpath.
You've rattled through half the daily ES limit in an hour.

ES are expected with fastpath as there's no error protection on the line at all, but not to that extent.

Hi John,

Yes i did pull the plug after seeing those errors.

Engineer has been and he did indeed carry out more in depth testing etc and with the TDR and found a tiny spike about 150 meters away, which he said shouldn't cause too many issues.

Anyway, he performed a lift and shift, and whilst not improving sync speeds, has almost eliminated all the errors.

So far after one hour..

CRC: 0
FEC: 4
ES: 0

No phone plugged in at the moment but will leave it disconnected.

He suggested leaving it to settle for about 72hrs.

Just thinking out loud here...

Surely, if i was just swapped to a different port on the same card, it wouldn't necessarily improve anything if the card was at fault?

Logs this morning are..

CRC:184
FECS: 8628
ES: 90

I haven't dared to try the phone again yet!

The line running perfect until you connect a DECT phone is unlikely to be a dodgy line card.

When using a DECT phone are you connecting it to a power socket that's right next to the master socket?
If so have you tried using another power socket?

Are there any other extensions in the house?

I haven't dared to try the phone again yet!

The definition of insanity is doing the same thing over and over and expecting different results.

In reply to a post by j0hn83:

The line running perfect until you connect a DECT phone is unlikely to be a dodgy line card.

When using a DECT phone are you connecting it to a power socket that's right next to the master socket?
If so have you tried using another power socket?

Are there any other extensions in the house?

Must admit, i was thinking the same.

The phone is powered from a socket the other side of the room on a short extension lead. I was thinking that maybe the power socket that the modem is plugged into may be contributing. I have a new one in the garage so i may swap it out anyway, as the wife has painted the current one.

No other phone extensions at all. Just the incoming cable into the master socket.

One thing i haven't tried is using a dangly filter in the test socket with the phone and dsl plugged in, to rule out a dodgy 5C faceplate.

In reply to a post by j0hn83:

I haven't dared to try the phone again yet!

The definition of insanity is doing the same thing over and over and expecting different results.

You ain't kidding!

I think the most frustrating thing is a) losing a huge amount of sync over night (and none of the engineers can explain - rein, crosstalk& capacity issues have been ruled out) & b) now the line is stable, every time i plug my phone in, i lose even more!!!

I advise running the test socket experiment next.

A point on the comment about crosstalk...

No idea who told you crosstalk was ruled out, but unless they have a magic crystal ball I've no idea how they could possibly think to know crosstalk wasn't the reason.

Crosstalk can start on the line at any time.
The engineers may only connect new lines during the working day but a new line won't cause crosstalk and reduce your sync until that customer connects their modem. They can do this at anytime, midnight if circumstances required it.

A single engineer can't know every line that's activated on a cabinet, so if it was an engineer they are talking nonsense.
Former FTTC customers can be left jumpered to the cabinet and their line reactivated remotely. An engineer wouldn't know this has happened.

I've never seen an FTTC line that hasn't lost any speed to crosstalk, unless at the 40/55/80Mb cap for their package. Even then crosstalk has likely nibbled away at their attainable.
Some don't notice it as the lower SNRM targets can recover some sync.

I used to get 55Mb.
Crosstalk has dropped this to about 37Mb.
3dB SNRM increased it back to 45Mb.

You are on an ECI cabinet with no lower SNRM targets available to you so crosstalk would be noticed immediately and not covered up by DLM lowering the noise margin.

Edited by j0hn83 (Tue 22-Jan-19 11:38:18)

Thanks John,

It was a couple of engineers that mentioned about the crosstalk.

Did your speeds drop off quite quickly?

I only noticed mine towards the end of December, and when one of the engineers came, he showed me a sync graph on his phone showing green for many months, then overnight, dropped straight down into the red.

Hmmmmm ok.

Just removed the OR faceplate and plugged in a dangly filter and VDSL only, and my attainable and sync speeds have increased by around 4Mb each.

Not a great amount but still an improvement on before and makes one wonder about these filers that OR supply.

I was on 55Mb sync for about 9 months.
Then a neighbour ordered FTTC and the instant they connected their modem (I did it for them) my SNRM dropped a few dB, as did my attainable rate.
This didn't show as a deep in sync till I resynced my line.

Crosstalk from certain lines can be very very bad.
This is particularly bad with lines (pairs) that are close together (in the multi pair cables) for long distances to the cabinet.
Such a crosstalk can knock up to 20Mb off your sync as soon as they connect their modem. Yes you read that right, a single crosstalker can knock 20Mb off your sync.
It knocks so much off your SNRM it causes your line to immediately resync.

It just isn't possible to know if something is crosstalk unless you are in control of ALL the factors, which would require you to be controlling everyone's modems.

A drop in sync from a fault and a drop in sync from a new crosstalker can appear the same on a graph of your sync speed.

There's a reason most other countries run Vectoring (crosstalk cancellation) on their FTTC networks.
BT picked kit that doesn't do Vectoring unfortunately (ECI).

That's much more than I've ever seen a line improve just from removing a filtered faceplate, and suggests it's duff to me.

Wow, i didn't realise crosstalk could have that much of an instant effect, although it does make sense.

Yes, this morning i was syncing at just over 58, and removing the faceplate has pumped it up to just under 62.

Maybe something to note if anyone else is suffering with their sync speeds.

I will try the phone again later but i can't imagine this would make much difference, and certainly not enough to improve errors, so I will try and hunt down an unpowered phone, that will at least give me a missed called notification.

If the speeds stay good when using the test socket, then suggests a duff faceplate - what actual faceplate do you have, the one with a single socket (i.e. it does no filtering) or the one with two sockets? (i.e. phone and DSL sockets)

Some have moaned about the quality of the new 5C faceplates, alas due to curved shape not aware of any third party faceplates that would work. So suggest sticking to a microfilter for now

Hi guys, apologies for not keeping up to date.

Aaaaaaaaaanyway.......

Not sure where i got to but since my last post, the ISP (through no request from me) organised another OR engineer to perform a lift and shift and when he did this, for some reason had problems.

He called to say that another engineer was going back to the cab to sort it and eventually my sync came back the same..... fair enough.... and this was all sorted within an hour.

That night, re-synced at 54 so reported this and another engineer was arranged.

He knocked the door and said that he was asked specifically to do a lift and shift, and when i said to him that this was already done, he said there was nothing in the notes about it and probably wasn't.

So, off he went and he said you will be offline for around 30 mins which was fine with me.

In the meantime, i was informed that it had early indications of a faulty port.

Nearly two hours later he makes his way back and knocks the door. I asked if there was a problem and if everything was alright and he didn't really give an answer and was a little cagey, but he said have a look and make sure you are back on, and lo and behold, syncing at nearly 65! He also said that he was on the phone to his support team and they apparently did something their end as well, but wasn't sure what exactly.

So off he went and for the rest of the day and evening it was all working fine, holding at 65 with absolutely zero errors!....

CRC:0
FECS:0
ES:0

His notes were not all that specific once i had read them, so i don't know if the reason he was on the phone to support was trying to sort out a problem, or for them to assist with the lift and shift.

However, they did report that my sync was at 65 and all tested good!!!!

Yay!!!








Until this morning.....

Checked my stats and at 3am a re-sync saw me back down to 58, and i cannot see any reason why.

uuurggghh.

OK, Now i know the reason why.

OR did not do what they said they were going to do / had done.

It's no wonder they have such a bad rep.

Stay tuned for the next episode!

In reply to a post by Alucidnation:

OK, Now i know the reason why.

OR did not do what they said they were going to do / had done.

It's no wonder they have such a bad rep.

Compared to?

What are your day to day issues with streaming, downloading, browsing, etc?

Ok,

Left the line up and running without any interference from me and so far has been 'stable'.

Thought i would plug in the problematic phones to see how bad they affected the errors.

At first glance, it seemed to be very minimal, but after leaving it plugged in for around 10 mins they started to climb at a reasonable rate, although nowhere near as fast before.

So, IMO, whatever he did at the cab, did start to deal with the line issues, but appeared to be short lived and not as much as could be done.

Another engineer is booked for Tuesday so i'll keep you informed!

Assuming you haven't lost interest yet.

Ok, another update.

Engineer today has found a bad joint buried in the pavement outside where my line connects into the outside cable, however, this joint is inaccessible.

OR have now been out and marked where the joint is likely to be and are coming back to dig it up and investigate.

He said that if they still have a bad reading between there and my socket, they will install a new 'lead in'.

Getting there, slowly but surely!

Got up this morning to a heavily interleaved sync at 25Mbps with an attainable of around 62.

I have been keeping an eye on it for the last few days and there were very few errors at my end.

Expecting an update from OR on the 20th.

Ok, so either DLM is doing what it is supposed to do or it's messed up!

Got up this morning to another re-sync and this time, i am back to around 59.

Thought i would bring everyone up to speed (haha).

Speeds still all over the place, and still issues with the phones.

More visits, however, one engineer eventually conceded that there were still errors, mainly brought about by a high resistance on the line, and was decided it was certainly the joint in the ground outside.

Dig and fix team came and went and after a day or so, still the same.

Another visit, and he tested to the chamber from the cab and was getting 65 to that point but was dropping to around 50 at the test socket, even though it was all testing good. He decided apply for a new line to be run from the outside chamber into my house.

Had another chap today to measure up, who apparently, used to work this area but was moved a few years ago but was fairly experienced with the local network, did more testing and found that there was a high resistance joint about halfway between the chamber and the t joint outside my house.

He has put in for the repaired joint to be dug up again so that he can perform a test from that to the chamber, and that to my house, and then replace which ever part is faulty.

Phew.

Another update.

Turns out that it could be a faulty port.

Engineer tested it, and said it should be out putting 120Mb, but is only outputting 113 Mb.

Also turns out that the ECI cab has mostly first gen equipment so has been in use for a fair few years and could be starting to show its signs of age.