Anyone Using an Asus DSL-AC68U

bitsNbobs · 7 Jan 2015 at 02:25

RedBull2k said:
At the moment just for stability im connected with my ac-68u to my Openreach modem.

Connected like this there is no button in the gui for the spectrum to scan. Unlike in modem mode there is a button to scan. Is there anything to this?

Assuming thats a DSL-AC68U you are using and not their router only AC-68U device then using it as a router only will mean only the router side of the device is in use and not the DSL side. So no it would not be able to do spectrum monitoring, i would guess that option is only for when the device itself is generating modulation, rather than it montor the spectrum of other devices like a BT Huawei or B-Focus modem plugged into it. Based on posts though id still issue the command to kill spectrum to make sure.

Your stats are not much use, you need to be connected longer (several hours preferably days) rather than just a few minutes to get an idea of error rate, at connection time or just after you can normally expect the odd CRC error. A burst of CRC or FEC can be down to anything especially within the first few minutes.... Did you let the router sync and then switch on your computer that is sat right next to the router or power on something else like a hifi amp which is sat next to it? Doing that on a device sensitive to external noise like it seems the Asus is would likely cause a sudden burst of error (probably from EMI from the other device). If your router is next to other equipment you power on and off try if you can to move it and see if you still get the bursts of CRC/FEC.

EDIT: also why is yours saying Annex L? Are you in a country other than the UK?

RedBull2k · 7 Jan 2015 at 04:00

sorry, its the dsl-ac68u. i just wanted to show the high burst of the crc with spectrum being killed.

I dont know why its saying Annex L i will see if i can find the setting to change this.

babis3g · 7 Jan 2015 at 06:51

bitsNbobs said:
No problem babis3g on ADSL its not a bad idea to play about with bitswap, Trelis and SRA. Even more so if your line is capped at around 4Mb AND especially if the line (if it were not for the ISP speed capping) could handle more. Different combinations are sure to produce different results and with trial and error you may come up with a set of options that helps the connection stay stable, killing the spectrum as you and Ixel have been doing also looks like that helps so i recommend keeping that killed also.

For FTTC i can not say for certain though once i get a highly configurable device such as the Asus i guess being a FTTC user i will soon find out. There is definately something on the Asus though be it trelis, bitswap, SRA, a combination of them all or them plus something else that affects noise margins and error correction from what i have seen of the testing in here so far.

Apart testing, personal for my caped line ( & few others i have seen on fully adsl) is way better with each single dsl setting turned off disabled, as you mentioned in a post of yours upper (if i am not mistaken to turn off all settings)
See this post i can get quickly where asked the user to disable everything ... the second stats of the user is much better and snr has no dropped (adsl) with the same amount of time
Asus is aware about it but i don't know perhaps some conflict with mediatek hidden page (working in the background) & asus added dsl settings?
Same apply to me, everything disabled less errors , no drops of snr

http://forums.whirlpool.net.au/forum-replies.cfm?t=2331693

Ixel · 7 Jan 2015 at 09:33

Another update to say that I've not noticed a noticeable spike since yesterday, perhaps it was just a one off and not related to the ASUS at all on that occasion. Another observation is that the FEC is rising rapidly even though the connection is fastpath

.

Code:

near-end path0 fec:     147887636
near-end path0 crc:     10692
near-end fec sec:       57787
near-end err sec:       906
near-end ses sec:       46
near-end los sec:       0
near-end ua  sec:       58
far-end path0 fec:      186
far-end path0 crc:      17
far-end fec sec:        79
far-end err sec:        17
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=13.9 dB
AttenDown=10.4 dB
SNRMarginUp=12.4 dB
AttenUp=0.1 dB
DataRateDown=56035 kbps
DataRateUp=20000 kbps
FECDown=147872320
FECUp=186
CRCDown=10692
CRCUp=17
HECDown=0
HECUp=0
ADSLUpTime=1 day,  8:58, 50 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.0 dbm
PowerUp=6.2 dbm
AttainUp=29425
AttainDown=70600
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B

LordBarrass · 7 Jan 2015 at 14:45

I have noticed my connection is stable but seems to be about 7Mb/s slower than when it was on earlier versions of the firmware. Those were unstable and prone to disconnections. I will see about tweaking some of the settings to see if I can get my speed back up but still keep a stable connection.

bitsNbobs · 7 Jan 2015 at 17:01

babis3g said:
Apart testing, personal for my caped line ( & few others i have seen on fully adsl) is way better with each single dsl setting turned off disabled, as you mentioned in a post of yours upper (if i am not mistaken to turn off all settings)
See this post i can get quickly where asked the user to disable everything ... the second stats of the user is much better and snr has no dropped (adsl) with the same amount of time
Asus is aware about it but i don't know perhaps some conflict with mediatek hidden page (working in the background) & asus added dsl settings?
Same apply to me, everything disabled less errors , no drops of snr

http://forums.whirlpool.net.au/forum-replies.cfm?t=2331693

What i would do personally if i were to start trouble shooting is disable every setting the Asus has (half of them should not make much difference in real life but they seem to) BUT ONLY ONES which could potentially affect a routers noise margins and speeds.
Once done, monitor the connection for a day or 2 and then enable one of the settings, monitor again for a day or 2 and if its still stable enable another setting, monitor again.

Continue this pattern until you find what you think is the problem setting. THEN to make sure it is just one or two settings you disable everything else (IE see no other option setting is interacting) and just enable the problem ones, if the line remains unstable you have found the options/settings which are not suitable for your specific service.

A pain and long work (possibly weeks of effort) but thats one way.

Its interesting my theory that disabling a bunch of stuff (atl east for ADSL) is partially true, i personally think some of the algorithms on the ASUS interfere with each other and thats what causes half the issues.

Ixel said:
Another update to say that I've not noticed a noticeable spike since yesterday, perhaps it was just a one off and not related to the ASUS at all on that occasion. Another observation is that the FEC is rising rapidly even though the connection is fastpath .

The Asus has to be including something in that FEC figure apart from actual errors that have been corrected, i personally think everytime trelis, bitswap or SRA are making an alteration (or maybe something else entirely yet to be discovered BUT STILL relating to db or noise margin), the FEC monitoring algorithm on the Asus thinks its seeing errors. (IE a bug in the monitoring)

FEC as you obviously know should be a ZERO if you are on Fastpath so the device is obviously counting something other than errors corrected by interleaving. Personally as discussed before i would not worry about the FEC count, as IMO its not accurate anyway. Though how inaccurate it is who knows

LordBarrass said:
I have noticed my connection is stable but seems to be about 7Mb/s slower than when it was on earlier versions of the firmware. Those were unstable and prone to disconnections. I will see about tweaking some of the settings to see if I can get my speed back up but still keep a stable connection.

Possibly DLM has interleaved your connection, a fastpath connection which becomes interleaved can lose around that figure in speed. Check if you were on fastpath before and check if you are now interleaved before you fiddle with settings.

PS a quick bit for everyone to remember. With the colder weather arriving people can expect more DLM and worse rather than better connections (at least for most people some lines ironically prefer it to be hot or cold) for a couple of months. Copper remember contracts when it gets cold, for roughly 6-7 months or so of the year in this country the weather temperature wise is pretty constant, but when a hot summer arrives or a cold winter then its not unusual to see all types of weird things happen to a XDSL connection over what it does for the other 6-7 months of the year.

Ixel · 7 Jan 2015 at 18:57

Due to an earlier fault at the exchange I had to switch to the ECI with the RT-AC68U connected to that (due to tests and such, prior to a possible engineer callout - as I pay for critical care someone might've turned up as early as later today).

I'll be switching back to the ASUS DSL-AC68U later this evening, and when I do I'll turn off TCM. For now I will have to keep disconnections and changes in sync speed to a minimum as my connection is currently (and temporarily) being monitored due to the recent fault report - so I don't want to throw anyone monitoring my connection into confusion and finding an engineer was requested unnecessarily.

bitsNbobs · 8 Jan 2015 at 01:29

Ixel said:
Due to an earlier fault at the exchange I had to switch to the ECI with the RT-AC68U connected to that (due to tests and such, prior to a possible engineer callout - as I pay for critical care someone might've turned up as early as later today).

I'll be switching back to the ASUS DSL-AC68U later this evening, and when I do I'll turn off TCM. For now I will have to keep disconnections and changes in sync speed to a minimum as my connection is currently (and temporarily) being monitored due to the recent fault report - so I don't want to throw anyone monitoring my connection into confusion and finding an engineer was requested unnecessarily.

If the engineer resets your line profiling it will be interesting what the Asus makes of that in terms of error counting etc.

RedBull2k · 8 Jan 2015 at 03:24

how do i get a hold of tc console? i had it for my n66u, off of support do i need to go down the same route

Ixel · 8 Jan 2015 at 10:11

I'm not sure if the version of TC I've got works on the N66U, I presume it does though and is just a universal tool. Send me a trust message and I'll provide you with the original URL for the 24 hour diagnostic.

-----

I'm now back on the ASUS DSL-AC68U as the fault is closed and my connection's no longer being monitored for stability. I've disabled TCM and synced my downstream with a downstream rate of 48,999 Kbps - downstream SNRM is roughly 9 dB.

So far not a single CRC error on INP 2, delay 8ms, TCM disabled, bitswap enabled. Heavy rain outside at the moment.

Code:

near-end path0 fec:     81864
near-end path0 crc:     0
near-end fec sec:       1305
near-end err sec:       0
near-end ses sec:       0
near-end los sec:       0
near-end ua  sec:       0
far-end path0 fec:      8
far-end path0 crc:      0
far-end fec sec:        3
far-end err sec:        0
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.2 dB
AttenDown=10.4 dB
SNRMarginUp=12.3 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=20000 kbps
ADSLUpTime= 1:03, 27 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.3 dbm
PowerUp=6.1 dbm
AttainUp=29279
AttainDown=93000
ShowtimeStart=19
TotalStart=38
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B

EDIT 1:
2 hours and 12 minutes now, no CRC errors at all yet.

Code:

near-end path0 fec:     90042
near-end path0 crc:     0
near-end fec sec:       1434
near-end err sec:       0
near-end ses sec:       0
near-end los sec:       0
near-end ua  sec:       0
far-end path0 fec:      28
far-end path0 crc:      0
far-end fec sec:        7
far-end err sec:        0
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

EDIT 2:
Over 4 hours of uptime and both FEC errors remained sensible and CRC errors remained at 0. I've now re-synced with identical downstream settings except for the INP is now 0 instead of 2, and delay is 4ms instead of 8ms. I'll provide an update shortly. TCM remains off.

ChazHurst · 8 Jan 2015 at 15:34

I've been silently following this product and threads like this one for a little while now and have come to the conclusion that, with the latest revision of the firmware, ASUS may well have sorted out nearly all of the trouble with the VDSL module in the router... (Please correct me if I'm wrong)

Being as there are so few single box options for VDSL modem routers this one does seem to stand out on it's own in terms of features and its proclaimed performance.

Would you say that the latest firmware upgrade has improved the user experience for the general home user on a typical BT Infinity VDSL connection?

Would you recommend to steer clear of this product still?
Do you feel that to get the wifi performance that this product offers it makes more sense to get a separate modem and pick and choose wifi routers from a much larger selection of well proven devices?

Ixel · 8 Jan 2015 at 15:37

ChazHurst said:
I've been silently following this product and threads like this one for a little while now and have come to the conclusion that, with the latest revision of the firmware, ASUS may well have sorted out nearly all of the trouble with the VDSL module in the router... (Please correct me if I'm wrong)

Being as there are so few single box options for VDSL modem routers this one does seem to stand out on it's own in terms of features and its proclaimed performance.

Would you say that the latest firmware upgrade has improved the user experience for the general home user on a typical BT Infinity VDSL connection?

Would you recommend to steer clear of this product still?
Do you feel that to get the wifi performance that this product offers it makes more sense to get a separate modem and pick and choose wifi routers from a much larger selection of well proven devices?

While ASUS are making improvements, the biggest issue is with the spectrum process. Killing it via telnet will solve the majority of problems it has caused - until ASUS issue a firmware update to fix that.

Other than that, some unexpected errors still remain but disabling trellis coded modulation (TCM) has ironically *so far* given me almost virtually no CRC errors yet. I'm just about to reduce the delay to 1ms with an INP of 0 - all other settings remain unchanged. I've just had 1 CRC error in the last 2 hours or so of uptime.

EDIT:
To answer some of your other questions. I still think this router/modem device has good potential and all lingering problems whether minor or major will be solved in the end. I've used an RT-AC68U's wireless capabilities and found them to excellent in my own experience, so the DSL version should be no different (I don't currently use wireless on my DSL version).

simoncraddock · 8 Jan 2015 at 23:04

Good to see real progress on this at last!

I've been loaned one of these again by a friend that runs a small local business. He's obtained a couple grade B units he is planning on using but isn't in any hurry. So I've hooked one up on the latest firmware and so far this evening it's actually been very stable.

Ixel · 8 Jan 2015 at 23:32

simoncraddock said:
Good to see real progress on this at last!

I've been loaned one of these again by a friend that runs a small local business. He's obtained a couple grade B units he is planning on using but isn't in any hurry. So I've hooked one up on the latest firmware and so far this evening it's actually been very stable.

Make sure you kill the spectrum process as it is still causing instability until ASUS make changes to that.

Do the following via telnet (e.g. using PuTTY software, and assuming you enabled telnet access via the administrative settings on the device):

Code:

killall -9 spectrum

But yes, excellent progress in improving the stability of this device is being made for sure.

EDIT:
Running on fastpath with TCM disabled, I did have a minor spike in CRC errors earlier, but other than that the combined ES/SES count is virtually identical to that which I'd get on the HG612. FEC isn't counting either, so maybe you're onto something with what you said @bitNbobs.

bitsNbobs · 9 Jan 2015 at 00:53

Ixel said:
EDIT:
Running on fastpath with TCM disabled, I did have a minor spike in CRC errors earlier, but other than that the combined ES/SES count is virtually identical to that which I'd get on the HG612. FEC isn't counting either, so maybe you're onto something with what you said @bitNbobs.

Well a bit early to let my head swell

But yep as said i would not be shocked if the FEC counter was counting stuff other than actual error correction when on interleave. The numbers seen by some reports were just too high, theres no way a connection with FEC up in the millions would even work reliably at the user end, you would be sitting there waiting god knows how long for all the errors to be corrected before even a basic web page loaded lol.

The FEC counter obviously has a bug or confuses itself with other modulation settings such as Trelis... Hopefully it is just Telis setting which stops it going totally haywire, i guess we will know after you have a few hours/days monitor to compare to the HG612. Though to be honest i suspect any setting which relates to modulation altering, the FEC algorithm will think is errors still.

Its kinda made me want to get an Asus even more now, call me crazy :eek:

but i like trying to solve weird things like that.

If it does turn out to be a bug to the FEC counter and FEC numbers rising because it is counting Trelis or similar alterations to the modulation as errors also, then i guess thats another thing for you current users to go report to that poor Asus guy (think without reading back his name was Paul) to try to solve lol.

One of the biggest issues is the Asus is it is sometimes too feature packed for its own good... The more stuff built in when coding the more chance you get something wrong with your code (the voice of unwanted experience)

Ixel · 9 Jan 2015 at 09:02

bitsNbobs said:
Well a bit early to let my head swell But yep as said i would not be shocked if the FEC counter was counting stuff other than actual error correction when on interleave. The numbers seen by some reports were just too high, theres no way a connection with FEC up in the millions would even work reliably at the user end, you would be sitting there waiting god knows how long for all the errors to be corrected before even a basic web page loaded lol.

The FEC counter obviously has a bug or confuses itself with other modulation settings such as Trelis... Hopefully it is just Telis setting which stops it going totally haywire, i guess we will know after you have a few hours/days monitor to compare to the HG612. Though to be honest i suspect any setting which relates to modulation altering, the FEC algorithm will think is errors still.

Its kinda made me want to get an Asus even more now, call me crazy but i like trying to solve weird things like that.

If it does turn out to be a bug to the FEC counter and FEC numbers rising because it is counting Trelis or similar alterations to the modulation as errors also, then i guess thats another thing for you current users to go report to that poor Asus guy (think without reading back his name was Paul) to try to solve lol.

One of the biggest issues is the Asus is it is sometimes too feature packed for its own good... The more stuff built in when coding the more chance you get something wrong with your code (the voice of unwanted experience)

My observations overnight were that FEC counted normal (in comparison to HG612) with TCM disabled. I need more uptime to be sure though. Unfortunately, for some reason, DLM intervened in the early hours of the morning - perhaps I mis-counted the number of synchronisations I had yesterday. As a result I'll need to remain interleaved and keep synchronisations to a minimum (e.g. no more than twice daily).

I'm currently on a downstream maximum sync rate of 64Mbps with an INP of 0 and a delay of 8ms - just 1 CRC error so far (considerably less CRC's/ES/SES than when I had TCM on - unless suddenly my line conditions have improved on interleaved (I doubt that). If things remain good for the next 24 hours then I'll bump the speed up to 74Mbps and continue monitoring for a further 24 hours.

cuke2u · 9 Jan 2015 at 17:16

9 days and 12 hours since my last wan disconnect, I wonder what the odds are on another overnight?

Ixel · 9 Jan 2015 at 17:32

Posting an update.

All seems well at the moment. Can TCM being on actually be adding to some issues? Hmm...

Almost 9 hours of uptime with TCM off, 64Mbps downstream sync rate, INP 0, delay 8ms:

Code:

near-end path0 fec:     169444
near-end path0 crc:     13
near-end fec sec:       1128
near-end err sec:       7
near-end ses sec:       0
near-end los sec:       0
near-end ua  sec:       0
far-end path0 fec:      2405
far-end path0 crc:      0
far-end fec sec:        91
far-end err sec:        0
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.7 dB
AttenDown=10.4 dB
SNRMarginUp=6.9 dB
AttenUp=0.1 dB
DataRateDown=63998 kbps
DataRateUp=19999 kbps
ADSLUpTime= 8:50, 41 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.9 dbm
PowerUp=4.4 dbm
AttainUp=26350
AttainDown=93160
InterleaveDepth=619
AdslStandard=VDSL2
AdslType=ANNEX_B

bitsNbobs · 10 Jan 2015 at 03:01

If you can when DLM has cleared off and you are fully back to normal Ixel check in Telnet if the "Kill" command for spectrum can also be used for Trelis.

That way in theory if you set Trelis to on/enabled or off/disabled in the web interface it should NOT turn itself back on (though whether that will work or not is another matter as "spectrum" it seems even with the kill command from reading can still become activate if you visit a certain page on the routers config).

You could also just as an experiment when back to normal see if you can use the kill command on bitswap, i know from conversation disabling that in the interface makes your connection fall flat on its face but maybe if it can be done killing via telnet that will work for you and also improve things even further.

Also as suggested to Babis3g disable SRA (seemless rate adaption) if you have not already. In fact if that can be killed in telnet also do it.

I reckon if all that also play a part in the FEC counter then killing it all may reduce the FEC numbers even further, possibly making it even more accurate and comparable even closer to the figures on your HG612

I had a play around with a friends Asus DSL-N66U (similar functioning device to the DSL-AC68U atleast options wise) today, reduced the FEC and CRC on his device by setting it to the right Annex (silly boy), killing spectrum (you can actually do it via telnet on that device and shell) and also turning off SRA which stupidly on his N66 device is set to on by default :rolleyes @asus:.

I then tested that for 2 hours and the FEC and CRC was reduced by half. compared to the 2 hours of testing before making the alterations.

I then fitted him a Mk2 VDSL faceplate and made him up a RJ45 (VDSL plate) to RJ11 cable (Asus N66) modem cable out of some nice FTP Cat6 and thats improved his stats by another db and improved max attainable sync rate by near another 3Mb

(RANT...why is it every modem/router no matter how high end comes with cheap poop 2 core flat non twisted modem cables????... It must save them all of about 1p in manufacturing, and cause grief to anyone with interference all around the world lol)

Tested for another 5 hours straight the longest that device has ever stayed synced on his line, off course could be down to just the cable and faceplate but considering i monitored for 2 hours before changing that and compared error figures to before making the router config changes i believe it all contributed in helping equally. SO another Asus success story, but again not without grief and work.

babis3g · 10 Jan 2015 at 03:09

@ bitsNbobs ... intresting finding ... will point this to asus

@ ixel ... what do you mean by TCM?

Thanks