Anyone Using an Asus DSL-AC68U
- Thread starter Socrates470BC
- Start date
I was intending to but I forgot to do so before re-connecting the cable after updating, as I had previously been playing around with the settings and then manually changed them through TC Console (making the GUI settings effectively not relevant any longer). Then when I restarted the router all settings I had manually changed via TC Console were lost and so the GUI settings were re-applied.
Associate
2 hours(ish) later and no change in the CRC count. So that's something at least.
Code:
outDiscards=251
inDiscards=32
outBytes=136452998
inBytes=351150631
outPkts=492433
inPkts=476134
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=24597
FECUp=16
CRCDown=551
CRCUp=2
HECDown=0
HECUp=0
ADSLUpTime= 4:23, 46 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=14.2 dbm
PowerUp=6.5 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=18673
AttainDown=93908
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)CRC errors still remain 0 here, FEC however is through the roof.
Clearly progress is being made. I'm interested to see how it will handle fastpath when I switch to it later this evening (with full 80Mbps downstream sync rate that is).
Code:
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 23953183(23952753)
near-end path0 crc: 0(0)
near-end fec sec: 13499(13499)
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: 2062(209416)
far-end path0 crc: 0(1160)
far-end fec sec: 27(4739)
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=484
inDiscards=23
outBytes=565124900
inBytes=3435114987
outPkts=2368457
inPkts=3062895
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=11.8 dB
AttenDown=10.4 dB
SNRMarginUp=12.7 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=23951565
FECUp=2062
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 8:13, 2 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.9 dbm
PowerUp=8.4 dbm
AttainUp=33488
AttainDown=109236
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplusClearly progress is being made. I'm interested to see how it will handle fastpath when I switch to it later this evening (with full 80Mbps downstream sync rate that is).
Associate
I had another batch of downstream CRCs in a short space of time, so sitting at 982 in over 7 hours connection time. To be fair to the DSL, I had seen similar with the Billion 8800NL in that I would get a burst every so often then all would be relatively quiet.
On the Billion, with the large bursts the ES count didn't increase at the same rate without appearing to impact the line. I suspect the reason that DLM intervened was one day I decided to check that it wasn't wiring in the house and probably had one too many disconnections for its liking.
Least I've not had the 5000 CRCs in a short burst, yet, that was regularly happening on older firmwares.
On the Billion, with the large bursts the ES count didn't increase at the same rate without appearing to impact the line. I suspect the reason that DLM intervened was one day I decided to check that it wasn't wiring in the house and probably had one too many disconnections for its liking.
Least I've not had the 5000 CRCs in a short burst, yet, that was regularly happening on older firmwares.
I see. Good so far then.
Here it's proving to be excellent (other than the FEC count), I will be interupting the connection in the next hour or so to switch to fastpath on 80M sync. Not a single CRC error!
Code:
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 37262819(37262143)
near-end path0 crc: 0(0)
near-end fec sec: 20405(20405)
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: 2407(209761)
far-end path0 crc: 0(1160)
far-end fec sec: 33(4745)
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=484
inDiscards=46
outBytes=702223663
inBytes=393361223
outPkts=3077299
inPkts=4094218
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.0 dB
AttenDown=10.4 dB
SNRMarginUp=12.5 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=37261351
FECUp=2407
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=10:11, 40 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.9 dbm
PowerUp=8.4 dbm
AttainUp=33488
AttainDown=111028
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplusEDIT 1:
Switched to fastpath, not increased downstream sync from 49M to 80M yet but will be in the next hour or so.
Code:
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 0(52455869)
near-end path0 crc: 16(16)
near-end fec sec: 0(26771)
near-end err sec: 14(14)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(31)
far-end path0 fec: 1090(211333)
far-end path0 crc: 0(1160)
far-end fec sec: 8(4761)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(333)
far-end ua sec: 0(14607)
outDiscards=278
inDiscards=82
outBytes=899890480
inBytes=1791472672
outPkts=3891256
inPkts=5244281
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=15.0 dB
AttenDown=10.4 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=0
FECUp=1090
CRCDown=16
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=51 min, 56 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.7 dbm
PowerUp=4.8 dbm
AttainUp=25872
AttainDown=91512
ShowtimeStart=18
TotalStart=37
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplusSimilar results to the HG612 so far.
EDIT 2:
Went to 80Mbps sync rate on fastpath and the results were plenty of CRC errors. Either the router doesn't handle a 6dB SNRM on fastpath well (for downstream) or my line would just perform that way now due to crosstalk or some other interference - sadly can't verify this as the HG612 will be speed banded to 49Mbps sync rate.
I'm now testing 80Mbps sync rate with 8ms delay and 0 INP.
Despite high FEC's so far, absolutely no CRC's.
80Mbps, INP 0, Delay 8ms, DSL-AC68U_3.0.0.4_376_2144-ga120ce8_DSL_1.0.1.9_1124.trx:
Code:
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 97044(52552913)
near-end path0 crc: 0(78)
near-end fec sec: 164(26935)
near-end err sec: 0(44)
near-end ses sec: 0(7)
near-end los sec: 0(0)
near-end ua sec: 0(108)
far-end path0 fec: 0(212902)
far-end path0 crc: 0(1160)
far-end fec sec: 0(4774)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(342)
far-end ua sec: 0(14664)
outDiscards=293
inDiscards=1126
outBytes=1117761026
inBytes=3471247675
outPkts=5994115
inPkts=9249751
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.3 dB
AttenDown=10.4 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79969 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=97044
FECUp=0
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=14 min, 31 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=4.7 dbm
AttainUp=25713
AttainDown=103156
ShowtimeStart=19
TotalStart=74
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=357
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Last edited:
Associate
Resync at 03:01 this morning - suspiciously around the time DLM would do its thing going from previous experience. Nothing seems to have changed though - downstream still interleaved and same pings as before. In the 5 hours connected, 4 downstream CRC and approx 205000 FEC.
Associate
- Joined
- 29 Sep 2014
- Posts
- 64
Firmware 2144 - current stats
Summary is that FEC is just short of 2000 per second and CRC up are approx twice the rate of the 2139 firmware. However, CRC down is still low (same on firmware 2139 for me).
Code:
outDiscards=748
inDiscards=3
outBytes=315392261
inBytes=1780862284
outPkts=928760
inPkts=1500112
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=152364567
FECUp=2235
CRCDown=4
CRCUp=87
HECDown=0
HECUp=0
ADSLUpTime=21:18, 5 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.3 dbm
PowerUp=4.4 dbm
AttainUp=21263
AttainDown=101084
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)Summary is that FEC is just short of 2000 per second and CRC up are approx twice the rate of the 2139 firmware. However, CRC down is still low (same on firmware 2139 for me).
Associate
- Joined
- 27 Oct 2014
- Posts
- 28
Ouch. Something seriously wrong there. Thats 150 FEC errors per downstream packet. I'm on FW 2144 and its good for me so far, much more stable and less FEC errors, although still about 1 per 10 d/s packets.
Associate
Maybe I should just buy one to join in the fun and games
The more people buying one and complaining, the quicker ASUS will iron out the issues. In theory anyway.
That said, 2144 seems to be a decent improvement over previous firmwares, for me anyway. 10 hours uptime since the resync at 3am with 4 downstream and 1 upstream. Although I do now have 21,779,632 FEC in those 10 hours.
Bearing in mind that my downstream is interleaved and I've downloaded 20Gb today, is that something to be concerned about? With interleaving and FEC going hand in hand, presumably the more you download the higher this number is going to be?
EDIT: Scrub that, even on an idle connection the FEC were increasing quickly. A resync seems to have sorted that out though.
Last edited:
Yeah, I agree, 2144 is definitely a noticeable improvement here as well. Still needs more work but it's at a point where I can now tolerate using the device with much less error correction (e.g. I can now sync at 80Mbps with a delay of 8ms and no INP and not get a single CRC for a duration which I tested at least more than half a day).
I'm now testing up to 80Mbps with a target SNRM of 9.0 dB, a delay of 4ms and no INP.
I'm now testing up to 80Mbps with a target SNRM of 9.0 dB, a delay of 4ms and no INP.
Code:
>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show Info_Adsl
up
near-end path0 fec: 1190(52777242)
near-end path0 crc: 11(1137)
near-end fec sec: 19(29029)
near-end err sec: 4(624)
near-end ses sec: 0(13)
near-end los sec: 0(0)
near-end ua sec: 0(226)
far-end path0 fec: 191(219704)
far-end path0 crc: 0(1160)
far-end fec sec: 2(4869)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(354)
far-end ua sec: 0(14773)
outDiscards=0
inDiscards=1647
outBytes=2470875815
inBytes=1330517267
outPkts=10198837
inPkts=14489057
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.0 dB
AttenDown=10.4 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=77379 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=1190
FECUp=191
CRCDown=11
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=12 min, 43 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=4.7 dbm
AttainUp=25713
AttainDown=94416
ShowtimeStart=19
TotalStart=150
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=158
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Has anyone tried the new 'enable dsl line diagnostic' option that's been added to the feedback section of the newest firmware releases? I'm not sure exactly what it does yet, but it requires a USB stick being plugged into the router so I assume it's some sort of line stat logging.
ASUS DSL-AC68U is rubbish at VDSL
Not sure if they got to the bottom of the issues on other ASUS routers or not. If they didn't, it does beg the question: why did they use the same modem if they knew is was crap.
Anyway, my advice would be to avoid this product at the moment....we just don't know if they'll ever get it sorted or if it will always be rubbish.
Apparently Billion have released a wifiAC router with a VDSL modem in it, that might be a better bet....although it's probably worth rooting around to find some users that have tried it before buying one.
http://www.billion.com/product/vdsl2/BiPAC8800AXL-VDSL2-Modem.html
Not sure if they got to the bottom of the issues on other ASUS routers or not. If they didn't, it does beg the question: why did they use the same modem if they knew is was crap.
Anyway, my advice would be to avoid this product at the moment....we just don't know if they'll ever get it sorted or if it will always be rubbish.
Apparently Billion have released a wifiAC router with a VDSL modem in it, that might be a better bet....although it's probably worth rooting around to find some users that have tried it before buying one.
http://www.billion.com/product/vdsl2/BiPAC8800AXL-VDSL2-Modem.html
I did actually look into that one but wasn't too sure on what sort of range it would have. I think I'm going to need something with fantastic range as I've just bought a new property and it is rather spaced out.
Associate
In which case you probably would be better off with a device with external antennae to help with range. The Billion devices (8800NL and AXL) both have internal antennae and I read a review of the AXL that the range wasn't as good as other routers out there, which isn't surprising with the antennae.