Anyone Using an Asus DSL-AC68U

I've been able to turn off interleaving (INP and delay) on the downstream fine here through TC Console, sadly the router isn't stable enough to stay connected and reasonably having CRC's under control, so I've had to stick to an INP of 3 and a delay of 8ms minimum so far. At least I'm now getting the sync speed I'm paying for though.
 
Last edited:
If only we could have a stats page along these lines (fictitious)...

Untitled_1.jpg
 
Last edited:
if i had a page like that i would be so happy! not sure why they assume there is information we shouldn't know. Even if you have to enable it manually
 
Since 3am this morning I'm now on the following settings and my ES/CRC is lower than it was by now (6 hours uptime at time of posting~), but it's still early days.

- Target SNRM 9.0 dB
- INP 3, Delay 8ms
- Max/min downstream sync rate 80Mbps/64Kbps
- Bitswapping disabled (RX & TX)
- Disabled DS3 due to high bitswapping history when observing from HG612
- DSL Settings: Changed RX AGC from 'Stable' to 'Disabled'

Points 1 and 4 seemed to make a difference, but it could just be a coincidence. I need to run it for more time to know for sure.

Code:
>wan vdsl2 show mgcnt;tcapi get Info_Adsl lineState;tcapi show Info_Adsl
near-end path0 fec:     40124946(132558252)
near-end path0 crc:     49(2403)
near-end fec sec:       23615(71263)
near-end err sec:       21(1164)
near-end ses sec:       0(31)
near-end los sec:       0(0)
near-end ua  sec:       0(246)
far-end path0 fec:      4195(57808)
far-end path0 crc:      0(1116)
far-end fec sec:        254(3000)
far-end err sec:        0(968)
far-end ses sec:        0(0)
far-end los sec:        0(189)
far-end ua  sec:        0(10915)
up
outDiscards=1
inDiscards=731
outBytes=1221675152
inBytes=2114564884
outPkts=5004115
inPkts=6654708
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=10.3 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=51547 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=40124941
FECUp=4195
CRCDown=49
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 7:02, 54 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.2 dbm
PowerUp=4.1 dbm
AttainUp=26477
AttainDown=70288
ShowtimeStart=18
TotalStart=94
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=3001
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

I'll catch up with any pending 'trust' messages later today.
 
Well I'm just waiting on PC World customer support to give me the nod on returning this device. I have the ZyXel I purchased on the cheap a couple of weeks ago and that will be sufficient for me I think for a while. I bought the Asus having purchased primarily Asus devices in the past (laptop, tablets, motherboards etc) and expected better.
 
I'll just go via my credit card company if PCW are funny.

Under the Sale of Goods Act 1979 goods must be as described, of satisfactory quality and fit for purpose.

The Sale of Goods Act makes reference to ‘the seller’, this is the shop, the retailer, or the individual you bought it from, and is who you made the contract with. It is not the manufacturer, and don’t let the shop tell you otherwise! If there is an obvious fault with the item at any time within the first 6 months and it has not been caused by wear and tear or misuse , your first port of call must be the shop you bought it from. They have the responsibility to put the matter right, and should not evade this responsibility by referring you to the manufacturer in the context of a guarantee or warranty. Even after this 6 month period, if the item breaks down prematurely , you should always go back to the shop or retailer in the first instance.

When you buy something from a shop you are entering into a legally binding contract. Therefore they don’t have to give you a refund simply because you have changed your mind. Only if one of your statutory rights is breached (i.e. that the item is damaged, of poor quality or not fit for purpose) do they have to give you your money back.

The Sale of Goods Act requires that goods be accurately described, of satisfactory quality and fit for any purpose specified. In other words, they must ‘conform to the contract of sale’. If this is not the case within the first 6 months after purchase, you have a range of remedies available to you which you should take up with the seller

If your goods fail to meet any of the above criteria then you could have a claim under the Sale of Goods Act.
 
Last edited:
Sorry, reason for my questions is that there is more than enough anectotal evidence on this thread and others (whirlpool, BT forum) to suggest that the DSL-AC68U is not a universal success when installed at many premises.

Indeed, I have an email from Asus suggesting that I return my unit to the reseller as not being fit for purpose.
 
ASUS have openly admitted there's a problem with the device in an email to myself so they shouldn't have much choice...

Please also help to inform others in UK that ASUS is aware of the issues customers currently encounter in UK in some cases, we are working hard on a solution and next firmware that could address such interruption issue will be released ASAP. Many thanks. Paul Lee - [email protected]
 
Last edited:
Can anyone else confirm this?

Early this morning I telnetted into the device and executed 'cat /tmp/adsl/info_adsl.txt'

I received this:

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.7 dB
AttenDown=10.7 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=48917 kbps
DataRateUp=15000 kbps
WanListMode=0
FECDown=1330224
FECUp=47
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=11 min, 40 secs


12 hours later I ran the same command and got exactly the same..

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.7 dB
AttenDown=10.7 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=48917 kbps
DataRateUp=15000 kbps
WanListMode=0
FECDown=1330224
FECUp=47
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=11 min, 40 secs


Either stats is broken or something weird is going on with my box.
 
Can anyone else confirm this?

Early this morning I telnetted into the device and executed 'cat /tmp/adsl/info_adsl.txt'

I received this:

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.7 dB
AttenDown=10.7 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=48917 kbps
DataRateUp=15000 kbps
WanListMode=0
FECDown=1330224
FECUp=47
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=11 min, 40 secs


12 hours later I ran the same command and got exactly the same..

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.7 dB
AttenDown=10.7 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=48917 kbps
DataRateUp=15000 kbps
WanListMode=0
FECDown=1330224
FECUp=47
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=11 min, 40 secs


Either stats is broken or something weird is going on with my box.

This happens when you enable bridgemode. Please use 'tcapi get Info_Adsl lineState;tcapi show Info_Adsl' via TC Console instead, if in bridgemode.
 
I haven't, that's what's odd

The plot thickens, I just did a spectrum scan and stats are now showing correct

FECDown=92169485
FECUp=13678
CRCDown=519
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=13:06, 26 secs

This is one screwed up device.
 
Last edited:
Huge number of FEC downstream

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=10.1 dB
SNRMarginUp=6.4 dB
AttenUp=0.1 dB
DataRateDown=69380 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=757309842
FECUp=5146
CRCDown=7
CRCUp=219
HECDown=0
HECUp=0
ADSLUpTime=4 days, 15:33, 37 secs
 
I have now disabled all ADSL tones (0-512) by setting the minimum DS tone to 520. I doubt this will make any difference to the instability/high FEC count but the way I see it is that there's no ADSL based noise/crosstalk on my connection then. It will be interesting to see if any difference is made to the FEC seconds.

n7nxwAp.png
 
I'm now at 26+ hrs uptime...

Whilst I realise FEC errors are due to Interleaving I'm mostly concerned with the increased number of CRC errors that I seem to get mostly at night on the Asus. I can go 8 hours daytime with just a handful, but overnight seem to chalk up over a thousand.

For once DLM didn't kick me last night and I have opted to keep the device for now. If I can't get satisfactory results from it then I'll run it purely as a wireless router with a modem thus keeping the 5Ghz AC1900 wifi, there was no real cash benefit returning it and swapping for just the RT wifi/router model due to similar price tag.

I still believe the firmware needs lots of improving, hopefully Asus will deliver.
 
Last edited:
I see.

So far so good, nearly an hour in and I appear to have considerably less FEC/FEC seconds then I usually would experience by now (hundreds of seconds, ten or hundred thousands FEC).

59 minutes~ uptime:
Code:
near-end path0 fec:  2773(289173208)
near-end path0 crc:     0(2603)
near-end fec sec:       35(150499)
near-end err sec:       0(1241)
near-end ses sec:       0(66)
near-end los sec:       0(0)
near-end ua  sec:       0(488)
far-end path0 fec:      413(84979)
far-end path0 crc:      0(1118)
far-end fec sec:        12(3378)
far-end err sec:        0(968)
far-end ses sec:        0(0)
far-end los sec:        0(203)
far-end ua  sec:        0(11049)

If it remains considerably lower than usual for the rest of today then later tonight I will reduce the target SNRM to 9dB and observe the result.
 
Last edited:
Well OR just visited my fixed my line - turns out the issue was at the pole outside this time but luckly there was another OR team working on the same pole at the same time.

The pole is a class D and can't be climbed using a ladder. Thankfully they fixed the issue otherwise I was advised it would have been another few days at least.

Just checked my sync speed [22399/8493] which is way down my approx 58Mb I was getting - now I'll have to see if BT will offer a DLM profile reset.
 
Back
Top Bottom