Anyone Using an Asus DSL-AC68U

Still a little buggy in the GUI, but connection still holding steady I guess...

stats_missing.jpg
 
simoncraddock said:
Still a little buggy in the GUI, but connection still holding steady I guess...

stats_missing.jpg
Click to expand...

why not show your stats ? lol

------------------------------------------

well i thought i would give the latest beta a wurl even though i had a uptime of 14 days + lol

iek2CiC.png

she is looking ok so far.
 
I've now switched to the settings posted by simoncraddock - hopefully they will help. I'll keep an eye on the TC statistics.

EDIT 3:
It would seem the answer is yes. That being I can override the downstream DSLAM parameters (including max sync rate). My line is banded 49/20 yet I've now been able to get 80/20 by setting the max sync rate to 10000 (x8) = 80000Kbps.

3905117273.png


This means the downstream DLM control can be overridden. Unfortunately this also may be susceptible to an abuser as this will most likely override even the 80 meg limit. However, I'm not interested in going beyond my package speed nor would I dare to try, but I do believe it would work (until you were caught perhaps by NOC, so I don't advise trying it).

EDIT 1:
Code: 
>wan vdsl2 show mgcnt;wan adsl perfdata
near-end path0 fec:     0(0)
near-end path0 crc:     24(193)
near-end fec sec:       0(0)
near-end err sec:       22(118)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(30)
far-end path0 fec:      63(17463)
far-end path0 crc:      9(1004)
far-end fec sec:        12(2148)
far-end err sec:        9(936)
far-end ses sec:        0(0)
far-end los sec:        0(129)
far-end ua  sec:        0(9314)
near-end FEC error fast: 0
near-end FEC error interleaved: 0
near-end CRC error fast: 24
near-end CRC error interleaved: 0
near-end HEC error fast: 0
near-end HEC error interleaved: 0
far-end FEC error fast: 63
far-end FEC error interleaved: 0
far-end CRC error fast: 9
far-end CRC error interleaved: 0
far-end HEC error fast: 0
far-end HEC error interleaved: 0
ADSL uptime : 1:09, 23 secs

EDIT 2:
Code: 
>tcapi show Info_Adsl
outDiscards=29
inDiscards=38
outBytes=513902708
inBytes=1472249995
outPkts=2267000
inPkts=2586042
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=16.0 dB
AttenDown=10.3 dB
SNRMarginUp=9.7 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=0
FECUp=69
CRCDown=28
CRCUp=10
HECDown=0
HECUp=0
ADSLUpTime= 1:20, 11 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.9 dbm
PowerUp=4.1 dbm
AttainUp=27753
AttainDown=96012
ShowtimeStart=19
TotalStart=38
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
 
Last edited:
simoncraddock said:
Early days but so far so good...

stats.jpg


Usually I've knocked up hundreds of CRC errors by now.
Click to expand...

I'd have thought that this would be expected since your connection is Interleaved rather than Fastpath - the whole point of interleaving is to add error correction after all.

I think you need to wait until your connection has recovered from DLM and is back on Fastpath before making any meaningful comparisons, assuming that you were not interleaved in the first place of course.
 
Ixel said:
I've now switched to the settings posted by simoncraddock - hopefully they will help. I'll keep an eye on the TC statistics.

EDIT 3:
It would seem the answer is yes. That being I can override the downstream DSLAM parameters (including max sync rate). My line is banded 49/20 yet I've now been able to get 80/20 by setting the max sync rate to 10000 (x8) = 80000Kbps.

3905117273.png


This means the downstream DLM control can be overridden. Unfortunately this also may be susceptible to an abuser as this will most likely override even the 80 meg limit. However, I'm not interested in going beyond my package speed nor would I dare to try, but I do believe it would work (until you were caught perhaps by NOC, so I don't advise trying it).

EDIT 1:
Code: 
>wan vdsl2 show mgcnt;wan adsl perfdata
near-end path0 fec:     0(0)
near-end path0 crc:     24(193)
near-end fec sec:       0(0)
near-end err sec:       22(118)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(30)
far-end path0 fec:      63(17463)
far-end path0 crc:      9(1004)
far-end fec sec:        12(2148)
far-end err sec:        9(936)
far-end ses sec:        0(0)
far-end los sec:        0(129)
far-end ua  sec:        0(9314)
near-end FEC error fast: 0
near-end FEC error interleaved: 0
near-end CRC error fast: 24
near-end CRC error interleaved: 0
near-end HEC error fast: 0
near-end HEC error interleaved: 0
far-end FEC error fast: 63
far-end FEC error interleaved: 0
far-end CRC error fast: 9
far-end CRC error interleaved: 0
far-end HEC error fast: 0
far-end HEC error interleaved: 0
ADSL uptime : 1:09, 23 secs

EDIT 2:
Code: 
>tcapi show Info_Adsl
outDiscards=29
inDiscards=38
outBytes=513902708
inBytes=1472249995
outPkts=2267000
inPkts=2586042
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=16.0 dB
AttenDown=10.3 dB
SNRMarginUp=9.7 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=0
FECUp=69
CRCDown=28
CRCUp=10
HECDown=0
HECUp=0
ADSLUpTime= 1:20, 11 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.9 dbm
PowerUp=4.1 dbm
AttainUp=27753
AttainDown=96012
ShowtimeStart=19
TotalStart=38
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
Click to expand...

Please Please Please tell me how to do that :)
my max sync rate is over 100meg :D just for ***** and giggles post the method and what tool required. also might help me get a even higher upload speed.
 
Evil Shubunkin said:
I'd have thought that this would be expected since your connection is Interleaved rather than Fastpath - the whole point of interleaving is to add error correction after all.

I think you need to wait until your connection has recovered from DLM and is back on Fastpath before making any meaningful comparisons, assuming that you were not interleaved in the first place of course.
Click to expand...

On interleaving you can expect FEC errors but CRC errors are un-related.
With my Zyxel (f1000) I was getting almost zero CRC errors over a 24hr period, yet the Asus would usual start churning them out after extended periods.

On this new firmware however it seems a great deal better...

Untitled.jpg


This would seem to be one of those devices that you need to tweak to suit your line rather than being one that just works out the box. One setting doesn't work for everyone unlike with some.
 
Last edited:
ViRuS2k said:
Please Please Please tell me how to do that :)
my max sync rate is over 100meg :D just for ***** and giggles post the method and what tool required. also might help me get a even higher upload speed.
Click to expand...

I'm not sure if I'd be wise in explaining how to do this on a public forum. It might be better to PM me (trust). Any thoughts from anyone else? (e.g. whether I should post instructions here or whether I should keep it to a PM or what not)

Well, the bad news is while the connection was stable overnight, the CRC's racked up by around 7-8am this morning. Seems I get more errors during daytime than I do at night. I've temporarily resorted to interleaving my connection at 49/20 (INP 3, delay 8ms).

Code: 
>tcapi get Info_Adsl lineState;tcapi show Info_Adsl
up
outDiscards=250
inDiscards=8767
outBytes=490636901
inBytes=1327493447
outPkts=1085576
inPkts=1379443
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.1 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=2002704
FECUp=666
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 2:11, 11 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.8 dbm
PowerUp=5.0 dbm
AttainUp=25394
AttainDown=110704
ShowtimeStart=18
TotalStart=154
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

I will gradually increase the sync rate and/or reduce the INP/delay every 24 hours according to how many ES and CRC's there are on the downstream.
 
how the hell do you get out of bridge 4 mode lol after you change a setting....
as im connected at the new settings but no internet big yellow triange over my lan port :D
im guessing i have to get out of bridge mode 4 also can you email me the commands when you get a chance... for 80down 20up fast path and 90down 20up fastpath and 100down 25up fast path :D

cheers.
 
ViRuS2k said:
how the hell do you get out of bridge 4 mode lol after you change a setting....
as im connected at the new settings but no internet big yellow triange over my lan port :D
im guessing i have to get out of bridge mode 4 also can you email me the commands when you get a chance... for 80down 20up fast path and 90down 20up fastpath and 100down 25up fast path :D

cheers.
Click to expand...

Answered by email. I've yet to find a way to make multiple ports support bridgemode (not had the time to try) or to take a port out of bridgemode without a reboot. Changing the upstream speed isn't possible yet, unless there's a command somewhere that I've missed.
 
Ixel said:
Answered by email. I've yet to find a way to make multiple ports support bridgemode (not had the time to try) or to take a port out of bridgemode without a reboot. Changing the upstream speed isn't possible yet, unless there's a command somewhere that I've missed.
Click to expand...

thanks for the new commands mate. ;)
i will give those a try tommorow after work :D

though i know the 4th port cant be taken out of bridge mode like you said though if you find a way let me know.
now when applying the settings and pulling out the lanport and plugging it back into lan port 1 its showing a red x on my pc lan connection how do i get internet back after changing settings.....
 
I've gone back to the ZyXel I bought recently, the Asus was just chalking up way to many FEC errors behind the scenes. In 15 mins uptime over 1.5 million FEC errors, compared to roughly 2000 on the ZyXel.

I told Asus this morning that for the price tag and the type of user this gear is aimed at, the more line stats the better. They requested screenshots of my ZyXel stats page to look at. Whether or not they can or will improve the DSL Stats page is anyone's guess.

I really am close to just writing it off as an expensive mistake.
 
Last edited:
ViRuS2k said:
thanks for the new commands mate. ;)
i will give those a try tommorow after work :D

though i know the 4th port cant be taken out of bridge mode like you said though if you find a way let me know.
now when applying the settings and pulling out the lanport and plugging it back into lan port 1 its showing a red x on my pc lan connection how do i get internet back after changing settings.....
Click to expand...

You don't unplug from port 4, once you've applied the TC Console configuration you stay on port 4. It seems doing 'adslate bridgemode 4' causes all other LAN ports (1, 2 and 3) to be disabled, only keeping LAN port 4 enabled for access to both the router and modem firmware as well as internet access.
 
hmmmm
seems if we want to use this method then mate its going to require having a network switch to gain some ports back lol
 
FEC count

the Asus was just chalking up way to many FEC errors behind the scenes
Click to expand...

Interesting that you say that - just checked my stats via telnet and in one day, 17 hours or so my stats look like this:
FECDown=261849776
FECUp=738
CRCDown=3
CRCUp=89
HECDown=0
HECUp=0

I make that 261 million FEC - first time I have ever looked so nothing to compare against but it sounds awfully high.
 
sumowesley said:
Interesting that you say that - just checked my stats via telnet and in one day, 17 hours or so my stats look like this:
FECDown=261849776
FECUp=738
CRCDown=3
CRCUp=89
HECDown=0
HECUp=0

I make that 261 million FEC - first time I have ever looked so nothing to compare against but it sounds awfully high.
Click to expand...

Mine is doing the same while in interleaved. I can't make out if it's just the way it works, if it's reporting wrongly or if it's really errors being corrected. Personally I can't believe that many errors are happening. Surely there would be some noticeable throughput drop despite that many being corrected in such short time?

Code: 
>wan vdsl2 show mgcnt;tcapi get Info_Adsl lineState;tcapi show Info_Adsl
near-end path0 fec:      42614594(43207767)
near-end path0 crc:     553(397)
near-end fec sec:       22949(23517)
near-end err sec:       67(62)
near-end ses sec:       6(6)
near-end los sec:       0(0)
near-end ua  sec:       0(31)
far-end path0 fec:      3128(28229)
far-end path0 crc:      0(1062)
far-end fec sec:        74(2446)
far-end err sec:        0(968)
far-end ses sec:        0(0)
far-end los sec:        0(160)
far-end ua  sec:        0(10332)
up
outDiscards=752
inDiscards=330
outBytes=409402589
inBytes=1929182410
outPkts=1238474
inPkts=1719640
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.4 dB
AttenDown=10.4 dB
SNRMarginUp=6.5 dB
AttenUp=0.1 dB
DataRateDown=79991 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=42614822
FECUp=3128
CRCDown=553
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 8:58, 30 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=4.9 dbm
AttainUp=25327
AttainDown=106748
ShowtimeStart=19
TotalStart=1090
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=424
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
tc>

I'm currently forcing my sync rate to be a maximum of 80000 and a minimum of 40000 downstream, not changed target SNRM (and yes I've just noticed that the target SNRM appears to still work fine even if you override the downstream parameters such as sync rates from the DSLAM). INP is set to 0 and delay is set to 8ms.

Some other interesting facts:
INP - This is independent of 'delay'. It doesn't seem to effect latency but does effect your sync rate (takes a chunk of it away depending on the setting).
Delay - This effects your latency, but does provide some means for error correction. Perhaps delay means the amount of time an error has in order to be corrected and not counted as a CRC (compared to the default of <=1ms on fastpath).

At least that's been my observations so far. Unfortunately I still haven't found a way to override the upstream parameters. This means on my connection DLM has applied an INP of 4 and a delay of 8 on my upstream, which I imagine it'll remove in the next few weeks as I don't get many errors on the upstream to warrant it anyway.
 
Last edited:
Access to stats

wan vdsl2 show mgcnt;tcapi get Info_Adsl lineState;tcapi show Info_Adsl
Click to expand...

Out of curiosity, in which tool are you executing the stats command? I'm outputing the adsl stats from /tmp/adsl to the console which seems long winded - would be great to have access to the information another way.
 
Ixel said:
Mine is doing the same while in interleaved. I can't make out if it's just the way it works, if it's reporting wrongly or if it's really errors being corrected. Personally I can't believe that many errors are happening. Surely there would be some noticeable throughput drop despite that many being corrected in such short time?
Click to expand...

I got punished by DLM again whilst using the Asus on this new firmware, knocking me down 2mbps and increasing the Interleaving depth. Grrrr

One thing I pointed out to Asus which they have so far declined to answer is why my 'Attainable Rate' is almost 20mbps higher using the Asus compared to the 4 other devices I have. My theory is that its this that's causing line instability.

The ZyXel I have is so much more stable albeit at a lower 'Attainable Rate'.
 
Last edited:
So this router can let you alter the SNR on the downstream for a higher sync, say a 3dB profile rather than the usual 6? How does the DLM react to that?
 
You must log in or register to reply here.
Back
Top Bottom