New Router - VR900 V2 Stats

Can someone who understands all this let me know what this means, I've been interleaved for ages, I think due to the old router being an Asus DSL-AC68U which didn't support G.INP, the new one as far as I'm aware does, but I seem to have a lot of errors on the download...

see stats...

Line Status:
Connected
DSL Modulation Type:
VDSL2
Annex Type:
Annex A/L/M
Upstream Downstream
Current Rate(kbps) 20000 55000
Max Rate(kbps) 30374 82512
SNR Margin(dB) 12.5 13.3
Line Attenuation(dB) 7.5 2.6
Errors(pkts) 25 5811

StatPoster software gives the following...

2018.05.16 18:07:44 xDSL Stats (1st,Auto):
[1,0,0,0,0,0]0
enable=1
status=Up
linkEncapsulationRequested=
linkEncapsulationUsed=G.993.2_Annex_K_PTM
modulationType=VDSL2
lineEncoding=
allowedProfiles=8a,8b,8c,8d,12a,12b,17a,30a
currentProfile=17a
X_TP_VDSLProfiles_8a=1
X_TP_VDSLProfiles_8b=1
X_TP_VDSLProfiles_8c=1
X_TP_VDSLProfiles_8d=1
X_TP_VDSLProfiles_12a=1
X_TP_VDSLProfiles_12b=1
X_TP_VDSLProfiles_17a=1
X_TP_VDSLProfiles_30a=0
dataPath=
interleaveDepth=0
lineNumber=0
upstreamCurrRate=20000
downstreamCurrRate=55000
upstreamMaxRate=30344
downstreamMaxRate=82520
upstreamNoiseMargin=125
downstreamNoiseMargin=133
upstreamAttenuation=75
downstreamAttenuation=26
upstreamPower=-104
downstreamPower=131
usNegBandPlanDiscPresentation=3
dsNegBandPlanDiscPresentation=3
SATNus=35,68,93,1023,1023
SATNds=34,67,112,1023,1023
LATNus=35,75,100,1023,1023
LATNds=26,68,112,1023,1023
SNRMarginus=123,127,124,-512,-512
SNRMarginds=133,133,132,-512,-512
transmitPowerUs=-240,-355,-106,-1281,-1281
transmitPowerDs=97,80,68,-1281,-1281
ATURVendor=
ATURCountry=
ATUCVendor=
ATUCCountry=
totalStart=85784
showtimeStart=32669
quarterHourStart=0
X_TP_Bitswap=On
X_TP_SRA=Off
X_TP_AdslModulationCfg=Multimode
X_TP_AnnexType=Annex A/L/M
X_TP_SupportAdslMode=VDSL2:A;T1.413:A;G.lite:A;G.dmt:A;ADSL2:A,A/L/M;ADSL2+:A,M,A/L/M;ADSL Auto Sync-up:A/L/M;Auto Sync-up:A/L/M
[1,0,0,0,0,0]1
receiveBlocks=0
transmitBlocks=0
cellDelin=0
linkRetrain=0
initErrors=0
initTimeouts=0
lossOfFraming=0
erroredSecs=0
X_TP_US_ErroredSecs=0
severelyErroredSecs=0
X_TP_US_SeverelyErroredSecs=0
FECErrors=20396
ATUCFECErrors=266972
HECErrors=234
ATUCHECErrors=0
CRCErrors=5811
ATUCCRCErrors=25
ATUCSeverelyErroredSecs=0
[error]0



can anyone tell me if there is an issue anywhere, sorry I don't understand a great deal of this stuff yet... or Should I ask my ISP to reset my connection to get me back to fast path?

It certainly looks capped, what speed are you paying your ISP for ?

it should be around 70-80MB - I think this is Dynamic Line Management in play, they are very slow in responding, emailed them about this over a month back, had [censored] all in response, so am wanting some advice from the community before I kick off with them again

I've just read (part skimmed) all the way through this thread about StatPoster and am not convinced about the interleaving information.

It does show a 0 in the Interleave depth field, but that has to be invalid. (Contrary to what kitz says in that thread). A value of 1 is Fast Path, as that means a packet is split across one packet. I.e. is not split. A higher number means interleaving is On.

However, as kitz correctly suggest, the presence of FECs on FTTC is inconclusive. There are two cases, G.INP inactive and G.INP active.

With no G.INP then on fast path there should be no FECs.

When G.INP is active the interleave depth is always one of 8 (most common), 12 or 16. But! The increase in latency we normally associate with interleaving is set to zero.

If full stats are available then other useful information is also present. The principle one being the presence or absence of Bearer 1 data. Bearer 1 is only present on G.INP and provides a signalling channel.

With G.INP active, not only do we (always) see a very low depth of interleaving, but we also see the delay parameter is zero for Bearer 0, but 3ms for Bearer 1. That parameter is what is added to the "fast path" latency.

See below, from a Billion router but the format is the virtually the same from most other makes. The Billion stats do not mention FECs, but in essence RSCorr (Reed Solomon Corrections) are the same thing

xdslctl info --show
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 13401 Kbps, Downstream rate = 66948 Kbps
Bearer: 0, Upstream rate = 13379 Kbps, Downstream rate = 66321 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): 5.1 6.0
Attn(dB): 19.3 0.0
Pwr(dBm): 13.7 7.4

VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 57
R: 10 16
S: 0.1172 0.5657
L: 17345 3592
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 72 0
TxQueue: 18 0
G.INP Framing: 18 0
G.INP lookback: 18 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 12670150
OHFErr: 0 157
RS: 3472541376 721872423
RSCorr: 612866 77
RSUnCorr: 0 0
Bearer 1
OHF: 6356544 0
OHFErr: 0 0
RS: 63564825 0
RSCorr: 422 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 2798 0
rtx_c: 2414 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 2 0
minEFTR: 66310 0
errFreeBits: 1194733521 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 137168739 0
Data Cells: 15690127 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: 12 362
SES: 10 0
UAS: 72 62
AS: 102104

Bearer 0
INP: 49.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 8.09
OR: 0.01 31.63
AgR: 66389.17 13410.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: 70623/74768 469/472

>

In reply to a post by Zarjaz:

It certainly looks capped, what speed are you paying your ISP for ?

It does look that way, yes. Since reading your post I've also found its predecessor, which does have some relevance.

yes, that's correct, should have followed up on that post.

I have replaced the DSL-AC68U, which was definitely interleaved up and down, this was detailed within the stats, the speed dropped significantly over the past month from around 70mb down to the 50mb down that I'm now seeing.

The VR900 V2 should be a better router/modem combo, but before I ask the ISP to reset or get the DLM reset, I need to make sure there are no other issues with the line.

RobertoS, thank you for the information, not sure I fully understood it, but shall read through the link you posted.

In summary of my post about the stats, when G.INP is active on a line then there is always a very small amount of interleaving, but in effect you are on fast path.

I believe the term "Fast Path" derives from the fact that pre-G.INP (in this country at least), interleaving always incurs higher latency than non-interleaved so has slower pings. Non-interleaved is therefore easier to refer to as Fast Path.

With G.INP, FECs and Fast Path are not incompatible.

Thanks, so back to the basic question, from the stats I posted should I still be in an "interleaved" connection, or should it rectify itself, or do I need to contact the ISP to get it sorted out?

Can't tell much from those stats except what Zarjaz said. I reckon you need to try to persuade your ISP to get a DLM reset done, but that could be very difficult.

At least I know never to get a TP-Link modem/router now .

Edit: What stats does it give as standard?

Edited by RobertoS (Wed 16-May-18 21:37:13)

Were there not �issues� around Cloudscape�s CS ? If true, then it seems even less likely they�ll request the reset the OP�s service needs.