New BB FEC errors

It's near a couple of extension sockets which includes a small mini fridge, however they're on 24/7 so it would stand to reason that it should occur at every other time too.

I did have the modem away from them before I bothered to screw it to the wall, and it made no difference then.

I guess it is something outside if its within a set time range, but random within there how bad it can be/when it happens. The 5/7pm spikes today were the earliest I've seen it.

Wish I could push for BT to hurry up with G.INP on the cab already. :mad:

Just as an experiment try moving the mini fridge away from the device if you can for a couple of days. Preferably place in on a different level in the house (IE if router is downstairs put fridge upstairs or vice versa).

It is possible that could be causing it (I frankly doubt it but its worth a try). Some of the cheap ones (with a tiny compressor and a Fan in the back but no cooling matrice) do cause electrical interference.

If router is plugged into an extension cable also try to eliminate that, again i doubt it will help but initially you want to try to eliminate anything obvious.

G.INP is unlikely to help much if at all on severe REIN, typically that helps more with general interference/line noise rather than REIN, its a tech based on tone allocation and if the REIN is bad enough to cause specific tones rather than the whole band to suffer there is not a lot G.INP is likely to be able to do. Would not matter how many bits got allocated to the REIN tones the REIN would still be there in pulses.

G.INP won't magically reduce the interference, I hope you're aware of that :)

What it will do is to significantly reduce the errors on the line (I had zero when I had it before DLM was reset) and thus sync speed will likely be higher and pings lower.

Vectoring will help with interference although it is primarily aimed at combatting crosstalk.

I'd be curious to see what the AC balance on your line is like. If you get another engineer ask them as the higher it is, the better the line is at rejecting interference. Above 50 is considered fine but ideally it would be 60+ (I've been told some pairs have AC balances of 80 or 90).

G.INP will not help bad or intermittent REIN its a tone allocation tech in simple terms on a normal line a persons tones are normally lower at specific points, G.INP identifies those and allocates bits to them, making for a smoother/more level tone allocation throughout the range and in most cases leading to a slight speed increase (typically 2-8Mb ish). Latency is increased when the tone allocation is taking place as obviously the protocol has to first think and figure out where to allocate things, which takes time.

Vectoring will not help at all, in fact vectoring on a line with REIN if anything could make it worse. The higher the tone frequency the more chance it will be affected by interference. Think of that like wifi and 2.4ghz vs 5ghz yes one can go faster but not as far and is more prone to errors. Vectoring when that (if that) gets here will basically for the most part affect short healthy lines more than long or noisy lines. The common denominator which will always stop long or poor quality lines improving on FTTC is the copper no matter what tech you employ you can not break the laws of physics or ohms law.

AC balence can only be measured on the analog (copper side) AFAIK (though i have not been in the job for more than a few years) of the line, measuring it at an end users premises which has FTTC is counter productive as you are not measuring the entire loop (though again maybe there is a way now). Voltage would be far more interesting and if that fluctuates.
DLM only occurs in the early hours of the morning so I don't think it would be that?

Small correction NORMALLY only in the early hours, Ive seen it make alterations as late as 11.30am in the morning, typically it kicks in between midnight and midday. With minor changes (IE interleaving being enabled or disabled) occurring between 1-6am.

It happened at 6am because the ES went over the limit because of the huge burst of 1200 ES in a single hour, noticed interleaving is back on.

If its confirmed REIN there's really sod all I can do about it since it can't be internal. :(

If the interleaving helps (measure your line again over the next few days) then it is possible the REIN is not too bad and your line may go back to fastpath, the DLM system will likely have a fight with itself as to what it thinks will be best LOL. The bad side if the REIN is not that bad and interleaving helps it is that means the source will be even harder to find.
 
The problem is the first time DLM kicked in it never changed at all, it just stuck that way for the next 3 weeks, and that seemed quite aggressive to me because when the interleaving was on the errors were reduced to single digit figures per hour (1-3). So interleaving DOES help, I just don't like it because it ruins my ping. :(

So yes, the first time I had a huge error spike that turned on DLM, (interleaving depth of 1336) it reduced my errors to pretty much nothing, but from that point on the DLM never changed at all. So, from what you say, my line is actually pretty good normally, and any REIN will be hard to find?

I'll try your experiments but yeah I don't hope for much.
 
Last edited:
It happened at 6am because the ES went over the limit because of the huge burst of 1200 ES in a single hour, noticed interleaving is back on.

If its confirmed REIN there's really sod all I can do about it since it can't be internal. :(

DLM only acts in the night. It never acts during the day.

Edit: I stand corrected. Poster above is right.
 
Last edited:
My issue with interleaving is that it masks the issue to some extent.

The line will generate hundreds of thousands of FECs but because they aren't actually errors, they won't be counted as the conditions of a fault but the fact is, they are indicative of some level of interference because data is having to be corrected all the time.

It would be (IMO) useful if when an OR engineer was visiting, they could temporarily disable DLM and set the line to a wide open profile. I expect in Tephnos' case, the CRCs would be ridiculous and thus evidence of the true issue here.
 
My issue with interleaving is that it masks the issue to some extent.

The line will generate hundreds of thousands of FECs but because they aren't actually errors, they won't be counted as the conditions of a fault but the fact is, they are indicative of some level of interference because data is having to be corrected all the time.

It would be (IMO) useful if when an OR engineer was visiting, they could temporarily disable DLM and set the line to a wide open profile. I expect in Tephnos' case, the CRCs would be ridiculous and thus evidence of the true issue here.

As mentioned CRCs aren't ridiculous at all except at night and have generally been 'ok' until last night when they went nuts. BitsNBobs seems to assume because of that the line isn't actually all that bad (it's not, never drops or anything) so DLM taking action is my biggest issue.
 
The OP definitely disappeared! My only hesitation would be there's a LOT of good info all this one thread which will be handy to others, splitting it up wouldn't be such a great idea.

(REIN team showed up today, didn't expect that, thought it would be another engineer).
 
They're going to come back in a few days at 9PM, when it happens.

They did say my SNR staying as stable as it does when the errors are spiking is extremely unusual, and they're not sure what to think. He said if they find nothing, this is something new altogether and they'll need to call in the 'experts'.

It's always me.
 
Update:

They didn't come back, but instead this morning I got a resync and my interleaving is down to 8, which means G.INP!

Pings are back to being good and speed has slightly increased too, so hopefully that's the end of it!
 
The OPs issue is NOT likely to be a HR fault IMO. A HR fault will result (interleaved or not) in a far greater decrease in speed. His prior speed before any issues was 9Mb it is not about 7.5Mb that is a 1.5Mb loss (which would equate to the line now being interleaved).

A HR fault will also not necessarily show itself as noise on the phone line either. It is more likely to be seen as the connection having issues remaining connected when the phone is off the hook, in use or the receiver is placed back down. Those are the only time the SERIOUS voltage will change with a HR fault at the user end.

His post with 6 and 41 Million FEC and just under 8 hours of up time http://forums.overclockers.co.uk/showpost.php?p=28322398&postcount=12 is where he has resynced the line MULTIPLE times during a training period and INP has not been reapplied properly. Entirely normal to happen on an ADSL line if you keep resyncing it. INP values are calculated on a ratio of errors against uptime, keep restarting the connection and it has conflicting data on what the value should be. Resulting in a line which is still interleaved but with no INP to base the interleave calculation from.

Half his issues is he keeps resetting/restarting his connection, obviously in a vain and hopeless attempt in thinking suddenly he is going to get his 1.5Mb extra back. Though to be honest even if he didnt i doubt DLM will be able to sort things out, his line is just poor. Even before it had 'issues' http://forums.overclockers.co.uk/showpost.php?p=28315810&postcount=3 it was suffereing from LOF and LOS, which is far worse a problem than any errors.

His issue is more likely a Earth contact fault. Either in his property (old star based wiring which needs a refresh is an often culprit) or outside at cabinet or exchange. If the OP has a newer style faceplate the first thing he should be doing is trying the test socket. IF speed goes back up using that then he knows its likely poor cable termination his end.

If it is outside of his property (FAR MORE LIKELY IF BROADBAND IS THE ONLY ISSUE THE OP HAS AND PHONE WORKS FINE) its at the exchange and the reason its happened is because when he migrated the connection from SKY (LLU based) back to BT, BT in their infinite wisdom doing the lift and shift from LLU back to BT wholesale gear have decided to connect to an old bunch of pairs which have not been used in years. Probably corroded as hell and the lazy engineer couldnt be bothered to go get the emery paper before crimping him off. SOMETHING i hated when working for them and having to go fix other lazy individuals so called "work".

Calling BT and asking them to test the line (assuming you do not speak to another lazy idiot) should identify the fault. The OP can also try https://www.bt.com/faults which SOMETIMES will pick up line faults and even identify where the fault is.

Thanks for taking the time to reply with all this info.

I can confirm that we did have noise on the line and the ISP arranged with OR to look into it around the end of July. We did see an improvement after some intervention from OR occurred but since then we still have a noisy line and the broadband connection locks up. To clarify this locking up occurs at random times and when I've taken a look at the router stats there have been a very high level of errors, such as the examples I've posted in this thread. What I also notice is if I check speedtest.net it will fail the upload test. For some reason the router doesn't resync itelf even though the internet has become unusable. The ping and download speed are also affected but to a lesser extent. When we were with Plusnet and Sky our SNR Margin was lower and we have never had an interleaved service before. The reason we restart our router is because if we didn't we wouldn't have any usable internet service. We have been doing the whole house up so we haven't had the time to keep chasing up the ISP. The other thing that I've now noticed is that when I looked into the possibility of changing ISP, that our landline is not recognised as a BT landline but I understand our ISP uses some LLU in the exchange and is thus a BT Openreach landline but as yet is not showing up as such.

Earlier this week we have chased the ISP again over resolving this and yesterday OR confirmed to the ISP that they have cleared the fault. Last night the same thing occurred with the internet locking up. The router didn't experience any loss of service during the time that OR were attending the fault either, not sure if that is significant. Last night I had to restart the router to get the internet working again. Today's check of the router stats seems to show things have been more stable but we still have LOF, LOS, high SN Margin and an interleaved service. Our phone line does seem quieter today but it still feels as though we have a problem since SN Margin is higher than it was with previous providers and our service is slower than it was.

We no longer have the original daisy chained type telephone extension sockets since part of the work on the house has been putting CAT6 Ethernet around the house. There is now an Ethernet cable that is terminated on the extension IDC's of the vdsl interstitial faceplate which terminates to the patch panel the other end. We have tested the line in the test socket with the ISP who confirmed there to be a problem with the error rate with running their test connection to our router whilst plugged into the test socket of the master socket by removing the vdsl faceplate.


Uptime: 0 days, 10:54:49

DSL Type: ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]: 992 / 7,235

Data Transferred (Sent/Received) [MB/GB]: 179.57 / 3.20

Output Power (Up/Down) [dBm]: 12.6 / 0.0

Line Attenuation (Up/Down) [dB]: 23.8 / 43.0

SN Margin (Up/Down) [dB]: 12.0 / 12.8

System Vendor ID (Local/Remote): TMMB / ----

Chipset Vendor ID (Local/Remote): BDCM / IFTN

Loss of Framing (Local/Remote): 36 / 0

Loss of Signal (Local/Remote): 4 / 0

Loss of Power (Local/Remote): 0 / 0

Loss of Link (Remote): -

Error Seconds (Local/Remote): 106 / 0

FEC Errors (Up/Down): 0 / 116,787,795

CRC Errors (Up/Down): 3 / 70

HEC Errors (Up/Down): 0 / 332
 
Last edited:
The only other routers I have are another TG582N which is a Plusnet one with an older firmware and a Sky Hub. I would have to find out what my service password is because it's asterisked out in the current router settings. Might be able to then use the Plusnet router to test theory to some extent. The service was never interleaved with Plusnet though so if the FEC's are a weakness on the 582 then it might not prove anything.
 
something defo going on with interference on your line,
im using the same modem as you : just as comparison.

---
eadyXc1.png
 
The only other routers I have are another TG582N which is a Plusnet one with an older firmware and a Sky Hub. I would have to find out what my service password is because it's asterisked out in the current router settings. Might be able to then use the Plusnet router to test theory to some extent. The service was never interleaved with Plusnet though so if the FEC's are a weakness on the 582 then it might not prove anything.

You can pretty much ignore the FEC count even though it should not be that high. You have some kind of line fault as is evident from the following in particular stats...
Loss of Framing (Local/Remote): 36 / 0
Loss of Signal (Local/Remote): 4 / 0
Error Seconds (Local/Remote): 106 / 0
CRC Errors (Up/Down): 3 / 70
HEC Errors (Up/Down): 0 / 332

On a decent working connection those should all basically be ZERO, the only exception being ES (error seconds) which some lines have the odd one)

Loss of signal and loss of framing are the telling stats, there is something wrong with the dsl signal. This will need a openreach engineer to check your wiring, the cabinets and the exchange. I would guess from how bad it is there is something wrong with the line card or your connection into it.

This is highly unlikely to be REIN or similar it is far too constant. Go back to your ISP and pester them until they authorise the correct type of engineer (not just a phone engineer/installer) to come out and fix this.
 
You can pretty much ignore the FEC count even though it should not be that high. You have some kind of line fault as is evident from the following in particular stats...
Loss of Framing (Local/Remote): 36 / 0
Loss of Signal (Local/Remote): 4 / 0
Error Seconds (Local/Remote): 106 / 0
CRC Errors (Up/Down): 3 / 70
HEC Errors (Up/Down): 0 / 332

On a decent working connection those should all basically be ZERO, the only exception being ES (error seconds) which some lines have the odd one)

Loss of signal and loss of framing are the telling stats, there is something wrong with the dsl signal. This will need a openreach engineer to check your wiring, the cabinets and the exchange. I would guess from how bad it is there is something wrong with the line card or your connection into it.

This is highly unlikely to be REIN or similar it is far too constant. Go back to your ISP and pester them until they authorise the correct type of engineer (not just a phone engineer/installer) to come out and fix this.

I think it was Thursday the OR engineer was meant to have sorted it and the ISP phoned wanting to close the job off but I wasn't happy to do that and they were meant to call again yesterday for feedback as to whether it had been resolved. Shall have to chase ISP again on Monday but it seems were stuck in a loop of problem acknowledged then OR brought into the equation and then back to square one.

We can't even see our phone number as a BT landline on an ADSL checker and we've had the line now for over 2 months.

My worry and belief is the error is intermittent, so it can be relatively OK and then something causes masses of errors. I wouldn't be surprised if the OR engineer doesn't find much unless by chance the error causing situation is occurring whilst the engineer has their test equipment connected.

It has been a little more stable, since it's not loosing sync or locking up due to the upload stream grinding to a halt but having checked the stats a while ago I can see it's pretty bad again.

Uptime: 0 days, 16:50:43

DSL Type: ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]: 986 / 7,115

Data Transferred (Sent/Received) [MB/GB]: 594.23 / 9.14

Output Power (Up/Down) [dBm]: 12.8 / 0.0

Line Attenuation (Up/Down) [dB]: 23.7 / 43.0

SN Margin (Up/Down) [dB]: 11.1 / 12.8

System Vendor ID (Local/Remote): TMMB / ----

Chipset Vendor ID (Local/Remote): BDCM / IFTN

Loss of Framing (Local/Remote): 90 / 0

Loss of Signal (Local/Remote): 10 / 0

Loss of Power (Local/Remote): 0 / 0

Loss of Link (Remote): -

Error Seconds (Local/Remote): 51,091 / 0

FEC Errors (Up/Down): 2,078 / 185,401,052

CRC Errors (Up/Down): 41,543 / 3,196,713

HEC Errors (Up/Down): 10,332 / 1,691,979
 
I'm pretty sure the FECs on Technicolor routers are complete rubbish but the CRCs and Error Seconds are worrying.

You need to get this re-raised as there is quite clearly still an issue.

I'd push for a pair change and lift and shift and if that doesn't help, I'd get a REIN case built.
 
I'm pretty sure the FECs on Technicolor routers are complete rubbish but the CRCs and Error Seconds are worrying.

You need to get this re-raised as there is quite clearly still an issue.

I'd push for a pair change and lift and shift and if that doesn't help, I'd get a REIN case built.

Does a pair change and lift and shift occur when changing providers? I think our present ISP uses talk talk LLU but we'd like to now go for fiber with a different ISP. Once we can get our landline to show up as a bt landline.
 
Does a pair change and lift and shift occur when changing providers? I think our present ISP uses talk talk LLU but we'd like to now go for fiber with a different ISP. Once we can get our landline to show up as a bt landline.

Depends on prior provider and new provider and if you are going LLU to BT wholesale or vice versa.

If you say (EXAMPLES ONLY) moved from BT to Plusnet (Both BT wholesale) then NO nothing would change line wise as its all BT whoelsale. The line is basically just then given new identification as Plusnet.

If you come/go to (or vice versa) a LLU to wholesale or a different LLU to LLU then the pair exchange end goes into different equipment.

If there is no noise on your phone this is an issue at the exchange side for the DSL. Faulty line card or port more than likely.
 
Back
Top Bottom