Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[phi2008]

I have an FTTC connection that has not had any problems since it was connected over 2 years ago, it's consistently connected at around 76Mb. Yesterday I noticed a few short blips where connectivity appeared to be lost, just out of curiosity I decided to swap out my ECI modem for an HG612 in order to have access to stats. The stats on the HG612's web interface didn't show any errors (zero in fact) and the line rate seemed fine, still just out of interest I downloaded DSLstats and set up an account at MyDSLWebStats.

After noticing a resync and drop to 62Mb overnight I looked at the error data on MyDSLWebStats to my surprise it turned out I was getting FEC errors of about 30,000/min before the resync and about 300/min after - the HG612 web interface had been showing zero errors. My HG612 is running firmware A2pv6C030b.d22g.

Here's why I am concerned, I am due to migrate to BT Infinity from Plusnet very shortly(7 days), however my experience of BT suggests moving to a very large ISP with offshore tech support would be a massive headache if you are trying to solve anything other than a very obvious line fault. They have millions of customers and they are not going to expend much energy helping the average person. So I will not migrate to BT if I believe I have the beginnings of a possible fault - I will migrate to a smaller ISP who can spend more time sorting things out, if that becomes necessary.

So I need opinions on my FEC rates in order to decide whether to ignore them and migrate to BT or play it safe and pick a smaller more customer focused ISP?  My username at MyDSLWebStats is "PhilStat" if anyone wants to look at the past 24 hours data.

[Chrysalis]

FEC directly have no importance as they are simply corrected errors.

Indirectly tho they are an indicator of how bad/good a line is and whether or not its worth persuing a DLM reset to get fast path back.

[roseway]

The error rates quoted in the HG612 GUI are mixed up, so take no notice of them. The correct figures are obtainable via the telnet interface, and these are the figures reported by HG612_Modem_Stats and DSLstats.

In general, FECs are of no significance. They are errors which have been corrected by the forward error correction system, so the actual data transmission is error free. What matters are CRCs and Errored Seconds (ES), which are 'real' errors. Looking at your MDWS graphs, your levels of CRCs and ES are tiny.

Your resync at 04:00 this morning appears to have been the result of action by DLM, as interleaving was increased at that time. All you can really do at this stage is continue to monitor your connection, and see what happens over the next couple of days.

[phi2008]

Just made a phone call which resulted in a spike of FEC errors, any idea what that signifies?

EDIT:

Whenever a phone is plugged into the Openreach faceplate the spike occurs ... normally my phone is unplugged.

[Weaver]

If this is a problem, and remember that most FEC events are potential errors that are successfully corrected by mathematical back calculation, then you could try a better microfilter. If you already have one of the high quality designed-for-VDSL faceplate filters, then try double-filtering the phone. Put a dangly microfilter into the faceplate's telephone socket, the Adsl Nation XF-1E say, and then plug the phone into that.

I once found I had to do this in order to prevent a DECT phone from messing up the signal-to-noise ratio when it went from on-hook to off-hook.

[Chrysalis]

so the phone was unplugged just before 4am when the FEC's went down to near zero?

I am interested in that sudden stop.

[phi2008]

No phone was connected before the arrowed spike. The graph scale is slightly misleading the FEC errors did not hit zero but stayed around 300/min after the resync.

[Chrysalis]

its not misleading in the scale of the drops, the 4am event is very important.  What happened at 4am? find that out, and you will get somewhere.

[phi2008]

As Roseway has pointed out 4AM looks like DLM -

[Chrysalis]

ok I looked at it a bit more, I agree it looks like a DLM event.

So you have 2 issues.

Your line has been stabilised by DLM at least twice, as it was already interleaved prior to the 4am event.  Given your high attainable speed, this to me suggests an underlying issue.  A line of your spec is unusual to require interleaving unless is a fault.

If a phone calls trigger error events, there is a possible nte5, or HR issue.

If simply plugging in a phone without been on a call triggers those FEC then the phone itself would seem to be a souce of interference, but you need to clarify was your phone previously unplugged all night then?

Is your modem connected to the master socket with a short cable?

What speed estimate did BT give you?

[phi2008]

The phone was unplugged overnight, I've ordered a new filter and will try that out if it arrives tomorrow. Modem connected with standard Openreach supplied cable, pre-installation speed estimate was a conservative 58(ish?) but as I've said I typically manage to sync at about 76Mb.

[mrpops2ko]

isn't A2pv6C030b.d22g the old firmware?

shouldn't it be;
Firmware version = A2pv6C038m.d24j

[phi2008]

Changed filter, same FEC errors, same phone spikes ... 

[NewtronStar]

Changed filter, same FEC errors, same phone spikes ... 

Which filter did you change was it a micro filter or the SSFP at the master socket ?
Has the Master Socket been fitted with an SSFP Mk2 or Mk3 

[phi2008]

Removed the broadband/phone socket combo faceplate leaving the unfiltered phone socket, then plugged in microfilter. Not sure what the difference is between Mk2/Mk3 so can't answer that - installed around Easter 2013.