Is that SP08 now?

After a bit of study, there are a couple of things that stand out, beyond the things I've already mentioned:

RS: 2219265617 3949549
RSCorr: 20892 11700
RSUnCorr: 0 0

These figures show that FEC is turned on, but is having almost no work to do - the number of RSCorr is really pretty low compared to the total number of RS blocks.

The relative counts suggests that there really isn't that much for FEC/interleaving to do - in either direction - so perhaps DLM intervention isn't really warranted.

RSUnCorr implies that FEC managed to fix all the faulty blocks. However, these stats ...

ES: 6 0
SES: 5 0
UAS: 127 127
AS: 15037

... strangely, tell us that some nasty things were happening. In particular, that CRC errors happened (even though RSUncorr was zero).

And it is pretty bad to see the SES counter as high as the ES counter.

Now consider the next two bunches of stats:

1)

Total time = 8 hours 44 min 0 sec
FEC: 48364 27567
CRC: 2945 0
ES: 6 0
SES: 5 0
UAS: 127 127
LOS: 5 0
LOF: 5 0

and 2)

Since Link time = 4 hours 10 min 35 sec
FEC: 20892 11700
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

Stats (2) match up with my comments for the earlier part - the FEC count matches the RSCorr count, and there are otherwise no errors at all; things don't seem too bad for this 4 hour period.

Altogether, stats (2) seem to show a rosy picture, for the most recent 4 hour period.

HOWEVER...

stats (1) shows how bad the previous 4hr 34min period must have been.

5 Loss of signal, 5 loss of frame, and an outage of 127 seconds says something isn't working well. Getting nearly 3,000 CRC errors within an 11 second period (5 ES plus 6 SES) is also rather bad - suggesting some really issues.

Stats (1) don't paint a rosy picture at all.

It is hard to correlate the behaviour seen in stats(2) against the behaviour seen in (1). That in turn suggests your line gets to see some intermittent problems.

Intermittent problems are the hardest to find, making 24/7 monitoring almost vital.

Once you have some basic monitoring running, there are some obvious things to check: Do high error rates occur at particular times of day? Do they happen with particular types of weather (heat, cold, rain, wind)? Do they happen when calls are made out? Or when calls come in?

In reply to a post by BatBoy:

I think so

I think so too.

If the SNR goes negative, when (at sync time) it will have started at 6dB, it suggests that noise has quadrupled. If that happens regularly, something nasty is happening.

Or it suggests a line fault - such as a high resistance fault (HR fault).

Does your internet connection stay up when you lift the handset off-hook? Or make a call? Or receive a call?

OK Interesting turn of events!!!!

Updated HG612 to very latest version of firmware: A2pv6C038m.d24j

This has now sent my line rate speed higher than ever before (67000kbps)

My line profile on BTw diag test has changed to 64mbps though still only able to acheive 50mbps (maybe needs time to update)

Latency has also reduced by a lot though a slight bit of interleaving still remains...

Not able to confirm yet as modems GUI won't show but I think G.INP has been activated..

Managing to read via Telnet...

In reply to a post by RobertoS:

Or the line you quoted "That's interesting -RetrainReasonNegativeMargin 2" [puzzled]

It is possible that the "retrain reason" value of 2 means that a negative margin was encountered.

There is a post on Kitz detailing this
http://forum.kitz.co.uk/index.php?topic=13934.110

The values may, or may not mean this.

I don't see any negative margin.

It really needs monitoring 24/7 to see if this actually happens.

On ADSL, my current line exhibited symptoms of an HR fault. Lifting the handset caused SNRM to drop - sometimes 2dB, sometimes 6dB. Sometimes it would cause a resync - though I never checked the reason.

When we finally got Openreach to get the fibre connection working, the HR fault was history, so I guess it was either in the E-side, or in the PCP. The last engineer suspected it would be at the MDF.

But we could only really tell what was happening by monitoring the SNRM with DSLStats.

Yeah - please post the telnet data, we can confirm the G.INP status - which would indeed explain the return of the headline sync speed.

I don't think interleaving and G.INP will co-exist.

It is more complex than that.

Bearer 0 - the main communication channel - can continue to be configured with some small level of FEC (around 5% overhead instead of 20% overhead). And it can continue to have a small level of interleaving configured (0.2ms instead of 8ms). Both of these have been seen on live lines.

The "heavy lifting" of coping with big problems (SHINE) is left to retransmission (ie the core new feature of G.INP), but very small levels of REIN continue to be handled by FEC/interleaving - or at least, things can be configured that way.

Bearer 1 - the channel that the re-transmitted blocks are sent down - is extremely over-protected by FEC but not interleaving interleaving. This channel (0.1Mbps) runs at 100% FEC overhead, so I guess it really wants the block to get through.

Sounds like an interesting mix of ideas

I've got the stats program working again now!!

Damn windows 10 previews :/

Right screenshot here!

G.INP is a go!

I think the firmware image i have has had the BT Agent removed from it, I'm not sure if this is important or not.