>tcapi get Info_Adsl lineState;tcapi show Info_Adsl;wan vdsl2 show mgcnt
up
near-end path0 fec: 5851(5851)
near-end path0 crc: 0(0)
near-end fec sec: 68(68)
near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 85(207439)
far-end path0 crc: 0(1160)
far-end fec sec: 2(4714)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(328)
far-end ua sec: 0(14579)
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=11.7 dB
AttenDown=10.4 dB
SNRMarginUp=12.6 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=5851
FECUp=85
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 1:06, 18 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.9 dbm
PowerUp=8.4 dbm
AttainUp=33488
AttainDown=106944
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Will do.
Even with the HG612 I had some CRC and ES, and usually a lot more FEC by now. So far I'm impressed (if the stats are really what they say they are). If by 6pm the FEC count and CRC is still extremely lower than usual then I will override the downstream DSLAM parameters (fastpath with up to 80Mbps sync rate) and test that. So far things are looking very good though, ASUS might have solved this at long last.
Using the beta, from the asuswebstorage link above, and it seems to be incorrectly reporting I'm on FastPath on the log page - my ping times are still 8ms higher than they should be due to DLM a week or so ago so I'm definitely still interleaved.
Will see how the CRCs pan out over time - 15 mins so far with 0 and I'd normally have a handful by now.
Since interleaving can be applied in both directions, is it possible that your interleaved in one direction but not the other? The status page doesn't make any distinction between up and down interleaving.
Possible I suppose. Definitely interleaved downstream since my sync rate reduced by about 10%, which is in line with DLM interfering. Upstream not affected, so that could be why it's showing FastPath right enough.
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 47867(47851)
near-end path0 crc: 0(0)
near-end fec sec: 1217(1217)
near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 1123(208477)
far-end path0 crc: 0(1160)
far-end fec sec: 12(4724)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(328)
far-end ua sec: 0(14579)
outDiscards=410
inDiscards=7
outBytes=267953896
inBytes=962813393
outPkts=902789
inPkts=1009486
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=11.4 dB
AttenDown=10.4 dB
SNRMarginUp=12.6 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=47843
FECUp=1123
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 3:45, 54 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.9 dbm
PowerUp=8.4 dbm
AttainUp=33488
AttainDown=105996
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
near-end path0 fec: 90186(90186)
near-end path0 crc: 0(0)
near-end fec sec: 1582(1582)
near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 1123(208477)
far-end path0 crc: 0(1160)
far-end fec sec: 12(4724)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(328)
far-end ua sec: 0(14579)
outDiscards=432
inDiscards=2
outBytes=61264397
inBytes=407330866
outPkts=211379
inPkts=319062
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.3 dB
SNRMarginUp=6.2 dB
AttenUp=0.1 dB
DataRateDown=69347 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=17404895
FECUp=30
CRCDown=0
CRCUp=3
HECDown=0
HECUp=0
ADSLUpTime= 2:28, 15 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.3 dbm
PowerUp=4.4 dbm
AttainUp=21267
AttainDown=101252
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1033
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
outDiscards=251
inDiscards=32
outBytes=99011126
inBytes=247274578
outPkts=348994
inPkts=327671
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.1 dB
AttenDown=11.6 dB
SNRMarginUp=6.2 dB
AttenUp=0.1 dB
DataRateDown=63119 kbps
DataRateUp=16994 kbps
WanListMode=1
FECDown=14961
FECUp=10
CRCDown=551
CRCUp=2
HECDown=0
HECUp=0
ADSLUpTime= 2:37, 50 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=14.2 dbm
PowerUp=6.5 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=18639
AttainDown=93472
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=913
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
Firmware 2144
No relief for the FEC count woes here - same rate as previous firmware at approx. 1950 per second.
2144 beta firmware
Still something not quite right, but I have to bear in mind it's gone dark now and there could be interference somewhere.
The burst of 551 downstream CRC were within a 10 - 15 minute window as I had checked the log, went off and did some other stuff, and happened to look back at the log page and went from 0 to that.
FEC is spiralling upwards here now. Will post stats before I change to fastpath soon. CRC's still remain 0 though.
At least we know the CRC counter is still working from that.
Can I ask what DSL settings you're on as my CRC's have just spiked again in the thousands?
Cheers
![]()
I was meant to enable UPBO (Auto) but forgot to do so on initial connection, so will leave it as that for the moment.