I can offer advice about reading the statistics. Others are better placed at offering advice about what to actually do with your line...
Am I right in thinking that the interleaving depth is rather high?
Not really. It seems to be about right for DLM intervention where G.INP isn't an option (and, on an ECI cabinet, G.INP isn't yet an option).
However, other parts of the DLM intervention are quite high - which taken altogether suggest that your line is seeing a lot of errors.
At this moment, the best thing to do is to keep monitoring the line, keep creating the graphs, and figure out when the errors occur. Because of the DLM intervention (on both upstream and downstream), interleaving was turned on alongside FEC (forward error correction) in order to make the FEC process more effective. For figuring out your line, pay most attention to the FEC counters (showing which errors were corrected by the FEC process), followed by the CRC and ES counters (showing the errors that were too severe to be fixed).
DLM decisions will be based more on the ES counters - so the ultimate aim is to reduce these - but for now, the aim is to check the pattern of FEC errors over time.
I've had FTTC for around 2 years now.
My line was previously syncing at full speed until late September, when I noticed my ping had increased to 19 from 5 (wasn't happy about this!) I also went down to a 70Mb sync.
Now, I have lost even more sync.
Over those 2 years, you've likely lost a lot of the "maximum attainable" speed to crosstalk - this is the noise and interference caused by other fibre subscribers. Crosstalk increases as take-up increases, but randomly. The increase in noise affects your own line in two ways: reduced speed capability, and increased errors. When the error rate increases enough to interest DLM, it intervenes to turn on both interleaving and FEC, which reduces speed even further, and adds latency.
The thing to work out, now, is how much of your problem stems from crosstalk, and how much from other events ... and whether there is anything that can be done about it.
Down Up
SNR (dB): 10.1 6.4
Attn(dB): 8.6 0.0
Pwr(dBm): 13.3 -9.6
That downstream attenuation, of 8.6dB, suggests you are very close to the cabinet - perhaps around 100-150m. I'd normally expect you to be able to achieve 80/20 unless you had a lot of crosstalk.
Strange to see an SNR of 10dB downstream. A value higher than 6dB should only happen when you have hit the upper speed limit of your package (ie 80Mbps, in this case). As this isn't the case, it suggests that the last resync occurred at a time when more noise was on the line than at present (4dB more).
That alone suggests it is worth watching the SNR graph to see how much variation you get.
Max: Upstream rate = 26010 Kbps, Downstream rate = 94696 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 63012 Kbps
I'll point out that your real "max attainable" speeds probably aren't that high. A "feature" of the HG612 is that, once DLM has intervened, it quotes attainable figures that are much higher than would be possible if DLM hadn't intervened. I'd expect them to be nearer 79/23.
Bearer 0
INP: 4.00 3.00
INPRein: 0.00 0.00
delay: 7 6
These are the main parameters that DLM changes when intervening. On most interventions, DLM works on the downstream alone, and sets INP to "3.00" and delay to 8ms.
If DLM intervened further, it would set INP to "4.00" and delay to 16ms. These settings control how much interleaving and FEC protection is agreed by the modems during sync.
However, when DLM has to intervene on both upstream and downstream together, it compromises on the two "delay" settings, so that latency does not increase too far.
Your settings, above, suggest that DLM has decided on a high level of intervention on the downstream as well as a low level of intervention on the upstream, with a compromise of a total of 13ms extra latency.
This suggests that you are getting high error rates on both downstream and upstream.
R: 16 16
D: 1369 341
I: 58 60
N: 58 60
These framing parameters are the ones chosen by the modems during sync, and specify how much FEC overhead has been allocated (R bytes in every N bytes), and how much interleaving.
Note that we don't care too much about the actual interleaving depth value; we already know (from the "delay" settings) how much extra latency is going to occur.
In downstream, your line is using 16 bytes out of every 58 as extra overhead (FEC parity data) in order to correct any errors that occur. That's 28% of your bandwidth used up ... which is a hefty proportion (standard intervention is usually less than 20%).
In upstream, the modems often turn on FEC without interleaving, to offer a little protection. Usually this has no impact on the overall throughput, as there is often spare capacity available. However, in your case, DLM has ordered interleaving to be turned on alongside stronger FEC settings. This is using 27% of your upstream bandwidth - but you have enough spare to cope.
Counters
Bearer 0
OHF: 86108555 3387060
OHFErr: 33 186
RS: 568767152 1925236
RSCorr: 498417 1162757
RSUnCorr: 336 0
These are the raw counters to be watched:
- RSCorr represent the FEC errors that were corrected
- RSUnCorr represent the FEC errors that could not be corrected; these lead to
- OHFErr represents the CRC errors that happen when uncorrected FEC errors happen
RS tells you how many blocks were transmitted, so the proportion of RSCorr to RS gives you an idea of how regularly errors occur. With those ratios - around 1 in 1,000 downstream look ok, but 1 in 2 upstream looks bad.
Watching the graph for RSUnCorr, to see whether it is consistent, or if there are peaks at certain times of day, can help determine what is the best way to fix things.
The graph for "FEC" is equivalent to the RSUnCorr one, except the values come from the summary statistics lower down in the output. You can look at that graph instead.
Previous 1 day time = 24 hours 0 sec
FEC: 426681 735161
CRC: 31 117
ES: 6 35
SES: 0 2
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
This section gives you an overview of "yesterday's" statistics (well, some 24 hour period). Here, it is useful to watch the ES counter, as DLM will be monitoring that.
Depending on your ISP, and the profile they used when ordering FTTC for you, DLM will watch the ES level as follows:
- If it goes above 1440 in one day, DLM will intervene, or increase the level of intervention.
- If it goes below 144, and stays below it for several days, DLM will reduce intervention or de-intervene.
(Thresholds can be 2880 and 288 on some ISPs like Plusnet).
Consistency is everything to DLM - so one bad day knocks you back severely.
Tracking the ES graph for consistency is very worthwhile.