HG612 Stats???

So we had a small power outage locally the other day and though I would check my modem to make sure no issues with DLM intervention maybe, well I'm happy to say that no DLM seems to of Intervened but I have notice in both the web based GUI and from Telnet that it is reporting a max attainable a lot lower than the current sync rate, Telnet output below.

xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 21227 Kbps, Downstream rate = 44168 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 65124 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.4 6.2
Attn(dB): 16.6 0.0
Pwr(dBm): 13.6 7.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 42
R: 10 16
S: 0.1193 0.3781
L: 17032 5374
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 51 0
TxQueue: 17 0
G.INP Framing: 18 0
G.INP lookback: 17 0
RRC bits: 0 24
Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 1715328
OHFErr: 0 90
RS: 3589186504 2956924
RSCorr: 2470 42
RSUnCorr: 0 0
Bearer 1
OHF: 6690801 0
OHFErr: 0 0
RS: 66907393 0
RSCorr: 12 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 40981 0
rtx_c: 291 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 0
minEFTR: 65109 0
errFreeBits: 106729919 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 574631499 0
Data Cells: 212493745 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 86
SES: 0 0
UAS: 24 24
AS: 107472

Bearer 0
INP: 47.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 65191.14 20063.54

Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
PER: 16.06 0.01
OR: 79.68 0.01
AgR: 79.68 0.01

Bitswap: 23910/23910 6342/6343

The connection is performing as well as it can with Plusnet, but hadn't come across this before.

Weird, certainly

ha, I forgot about this post... I haven't noticed this issues since!

The background noise was temporarily reduced so your modem could negotiate a higher sync speed than normal.

When the noise came back, the attainable sync speed dropped so if you resynced now the actual sync would go down to that speed.

But 60000 is my normal sync speed and still is too after many many reboots!

Post the stats now then, please?

As you wish!

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 22669 Kbps, Downstream rate = 63824 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 64673 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 7.4
Attn(dB): 16.7 0.0
Pwr(dBm): 13.5 7.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 42
R: 10 16
S: 0.1201 0.3781
L: 16914 5374
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 51 0
TxQueue: 17 0
G.INP Framing: 18 0
G.INP lookback: 17 0
RRC bits: 0 24
Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 502078
OHFErr: 0 1646
RS: 2099474144 945338
RSCorr: 39320 562
RSUnCorr: 0 0
Bearer 1
OHF: 108750567 0
OHFErr: 0 0
RS: 1087505058 0
RSCorr: 579 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 6574 0
rtx_c: 5297 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 14 0
minEFTR: 64657 0
errFreeBits: 1722590179 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2504246737 0
Data Cells: 1822023478 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 1553
SES: 0 0
UAS: 23 23
AS: 1746823

Bearer 0
INP: 48.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 64739.48 20063.54

Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
PER: 16.06 0.01
OR: 79.68 0.01
AgR: 79.68 0.01

Bitswap: 314836/314836 67046/67047

#

The actual sync speed and the attainable are now much closer together as I would expect.

When you synced this time the noise was slightly lower so a higher sync could be obtained. Now the noise has gone up slightly, a lower sync would be obtained if you resynced now.

In short, you've got nothing to worry about

I know that... I didn't resync last time when this happened... it was just random reading!

If it was due to the line temporarilty being unable to get more than 40000 then my speed tests wouldn't of continued at 60+ mbps!

The strangeness in the original set of stats is that the maximum attainable speed was much lower than the actual speed ... a set of affairs that normally goes alongside a low 'actual' SNRM value too.

However, the SNRM was around the, perfectly normal, 6dB figure.

The attainable value is a theoretical calculation that happens inside the modem, mostly based on the current SNRM value. At 6dB, it ought to calculate an attainable that is the same as the actual speed.

Of course, over the last 5 years, we've learnt to expect some discrepancies - especially when DLM has intervened old-style (before G.INP). But I've never seen one get it wrong as much as this before...

So what figure was being reported wrongly? A wrongly low attainable? Or a wrongly high SNRM?

The next place to look for evidence would be in the errors, starting with the ES figure. Nothing wrong there. Nothing in RScorr either. Nothing that shows that SNRM is running too low.

However, with G.INP, the next place to look is the "retransmit counters", and there is a little weirdity there: the rtx_tx figure is hugely higher than the rtx_c figure. This implies retransmission actually had to retry 41,000 times to get 291 blocks through successfully, though it looks like they did end up successful, as rtx_uc is zero. And LEFTRS (the ultimate indicator of throughput acceptability) is also zero.

Those values aren't extreme by themselves, but the ratio seems all wrong; on my line (up for 20 days), rtx_tx is 7,400 while rtx_c is 7,200 and rtx_uc is zero ... much more like the ratio I'd expect. And I still end up with a non-zero LEFTRS value (40).

Altogether weird. Not sinister, but weird.