Anyone Using an Asus DSL-AC68U

Good news so far!

Downstream 80Mbps, 0 INP, 2ms Delay:
Code: 
near-end path0 fec:     5299691(101620882)
near-end path0 crc:     65(186)
near-end fec sec:       2005(65048)
near-end err sec:       30(117)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(289)
far-end path0 fec:      2453(487948)
far-end path0 crc:      0(1944)
far-end fec sec:        31(8281)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(685)
far-end ua  sec:        0(29567)
outDiscards=928
inDiscards=357
outBytes=2490127745
inBytes=377644217
outPkts=28979421
inPkts=30758935
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.1 dB
AttenDown=10.3 dB
SNRMarginUp=6.6 dB
AttenUp=0.1 dB
DataRateDown=79972 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=5299691
FECUp=2453
CRCDown=65
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 6:11, 58 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=5.0 dbm
AttainUp=25260
AttainDown=103420
ShowtimeStart=19
TotalStart=187
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=88
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

Over 6 hours of uptime, minimal CRC errors (no spikes either). Normally without at least an INP of 2 and a delay of 4ms I wouldn't hold a stable and mostly error free connection. It's definitely more looking likely that the spectrum monitoring is causing the instability that many are experiencing. FEC still remains abnormally high, but hoping DLM doesn't consider it (will know after a few weeks of keeping below the MTBE threshold - which should be around less than 288 error seconds daily if I want a green status on DLM).

I'm expecting daytime ES/CRC trickling to become more regular, especially at this speed. If so then I'll nudge the delay up a millisecond or two and that should keep me below the 288 ES daily threshold for DLM's MTBE (on 'Standard' profile that is).
 
Last edited:
well i got to say THANK YOU ;) because even i suspected the spectrum ... if you did not had found the command to kill it .. we may not be able to test properly because each time the dsl part starts then the spectrum will be activated so will confuse us again

As for the fec errors i guess once running with hopefully less confict , it should be more easy for fine tuning bit swap if needs or drivers
 
I see. Well, lets hope we've identified the main source of the problem and that it's not just lucky at the moment.

I might set my 'RX AGC Gain Adjustment' back to 'Stable' again now that the problem has been identified (most likely) and temporarily resolved by a workaround. This should help to reduce the small but occasional trickle of CRC errors I'm getting. Currently it's disabled, which as far as I can tell from TC it just sets a chipset default of 440 (where the stable setting reduces it to 394).

EDIT: Nevermind it's actually set to 394 via TC already.

Unless I notice a large amount of errors happening then I'll leave it connected for until midnight tonight and see how the error seconds are. I may have to increase the delay by a millisecond or two however.
 
Last edited:
Excellent work guys, made mugs out the asus 'engineers', let's hope they listen to you and organise a firmware fix...
 
While to me the dsl drivers seems very good ...

Now lets look why very high fec errors :p (even if they are not bad)
I have one more suspect about it

Of course i am not sure and needs more testing ... because i don't have any professional program/software but only the basic internet tools for monitor asus which they are not 100% compatible

During the tests i have captured 3 logs
one with bit swap disabled
one with adsl swap only enabled
one with just vdsl disabled
(all other settings disable)

I have notice this ... (sorry my English is not that good to explain in a reasonable way but i am sure will get the point)

All examples lets say with in 20 min

-with bit swap disabled the bit swapping at the same tone will be lets say 3

-with bit swap adsl enabled the tones (at different tone or frequency this time of course) will be lets say 8

-with just vdsl bit swap enabled will be 16 bit swapping over the same tone (with about 20 min)

The more time the dsl connection is the more bit swapping over the same channel

My speculation is that having higher rates bit swapping (over the same tone???) may causing / creating more fec errors as trying to correct them over & over again???

From what i have seen with broadcom modems the screenshot i have at older post once the bit swap too place it will not count again swapping over it (perhaps if not needs any longer?)
With asus seems carry on over the same tone counting so fec errors appearing?

Here a screenshot which i just created to get what i mean but note is not actually both 3 test running same time but i just create them to get my point

UNLESS router stats is not counting correct because is not 100% compatible and counting wrong
Again i can be wrong but i would say asus to investigate it
 
Last edited:
Over 13 hours and all is fine still. Understandably the rate of error seconds has slightly increased compared to night time, this is normal for my line and not just specific to the ASUS thankfully.

@babis3g: I replied to the trust message (email), please send it over when you can - thanks.

Code: 
near-end path0 fec:     71737471(168056039)
near-end path0 crc:     563(620)
near-end fec sec:       26099(89139)
near-end err sec:       152(236)
near-end ses sec:       3(3)
near-end los sec:       0(0)
near-end ua  sec:       0(289)
far-end path0 fec:      6030(491525)
far-end path0 crc:      0(1944)
far-end fec sec:        97(8347)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(685)
far-end ua  sec:        0(29567)
outDiscards=1685
inDiscards=882
outBytes=1090555843
inBytes=3020116829
outPkts=33731547
inPkts=34596387
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.8 dB
AttenDown=10.3 dB
SNRMarginUp=7.2 dB
AttenUp=0.1 dB
DataRateDown=79972 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=71737471
FECUp=6030
CRCDown=563
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=13:05, 48 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=5.0 dbm
AttainUp=25579
AttainDown=113888
ShowtimeStart=19
TotalStart=187
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=88
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
 
Congratulations to all on here who are doing a fantastic job to try and find the problem/s
I don't understand most of it but as soon as someone says the problem/s is fixed then I will be grateful to all concerned and will unhook the Openreach and go back to using the router as it was intended.

Thanks to all, keep it up.
 
John40 said:
Congratulations to all on here who are doing a fantastic job to try and find the problem/s
I don't understand most of it but as soon as someone says the problem/s is fixed then I will be grateful to all concerned and will unhook the Openreach and go back to using the router as it was intended.

Thanks to all, keep it up.
Click to expand...

Thanks :).

I'm going to give it another 36-72 hours before I'm absolutely certain this is the cause of the problem (spectrum monitoring/the spectrum process). Once I'm sure it's the problem then I'll send an email off to ASUS (Paul Lee) and notify him of this, as I imagine babis3g will as well (if he hasn't already done so). I'm pretty confident that this was the problem however, as the current results so far have been the best I've seen to date.

I will post updates every few hours in the meantime. Hopefully the router won't uphold its reputaton for deception, where you believe a problem has been solved and then it returns.
 
John40 said:
Congratulations to all on here who are doing a fantastic job to try and find the problem/s
I don't understand most of it but as soon as someone says the problem/s is fixed then I will be grateful to all concerned and will unhook the Openreach and go back to using the router as it was intended.

Thanks to all, keep it up.
Click to expand...

Welcome & thanks
I am not sure if the problem solved 100% for all lines but for sure with spectrum totally disabled is way far better stable

we wait for Ixel what will report over time because my caped 4 mbps adsl (with low frequencies) line is not the best for testing stability compared lines with higher speeds
 
Ixel said:
Thanks :).

I'm going to give it another 36-72 hours before I'm absolutely certain this is the cause of the problem (spectrum monitoring/the spectrum process). Once I'm sure it's the problem then I'll send an email off to ASUS (Paul Lee) and notify him of this, as I imagine babis3g will as well (if he hasn't already done so). I'm pretty confident that this was the problem however, as the current results so far have been the best I've seen to date.

I will post updates every few hours in the meantime. Hopefully the router won't uphold its reputaton for deception, where you believe a problem has been solved and then it returns.
Click to expand...

Hi, yes i think is better/good idea really to keep it longer running

They are aware by now & they did send me a beta for bit swap test (i think for adsl) & is already running for about 2 hrs but its not the best day/night for testing because is peak time here & mainly my isp tonight has packet loss ( i ping my remote gateway with TBB and there is packet loss from time to time)

I need few days to say for sure if bit swap is better with my adsl line but at the moment with the simple tools i am monitoring is the same as with spectrum turned off, so looks promising

I am running now a debug with bit swap on (adsl) and spectrum on & later an other one with adsl bit swap on & spectrum off so i can send them early morning back to asus

Perhaps they should publish the beta if anyone has issues or feels to try it

EDIT
I can see from the debag tool some far end errors (from my isp) but has not effected me yet, dsl statistics at asus reports 0
 
Last edited:
I'm out of the loop here as I had to give up and return mine (need a reliable router for work) but I check back on the thread wanted to comment and praise the efforts of those who are getting to the bottom of the issues with this router

Fair play to all of you who are doing the manufacturer's work for them - can only hope you get a drink out of it if/when they get this product stable and reliable. If that hapens it will be thanks to you, not them.
 
plaistowpaul said:
I'm out of the loop here as I had to give up and return mine (need a reliable router for work) but I check back on the thread wanted to comment and praise the efforts of those who are getting to the bottom of the issues with this router

Fair play to all of you who are doing the manufacturer's work for them - can only hope you get a drink out of it if/when they get this product stable and reliable. If that hapens it will be thanks to you, not them.
Click to expand...

Thanks. Well, the modem is highly customisable so I kept it for that point alone. If it hadn't been for the instability problems I doubt I would've gained the tool for accessing the modem's operating system. However, I think we're finally near the point of resolving the instability this device has unfortunately received a somewhat bad reputation from. I can stick two fingers up at the DLM's setup on the downstream and specify my own sync rate, INP and delay :).

While FEC remains unusually high on interleaved (noticed this happens more often and more quickly on a higher sync rate/lower SNRM), CRC errors and error seconds/SES remain low and acceptable. I previously wouldn't have held a 80Mbps downstream with almost no interleaving, at best I would've needed an INP of 2 and delay of 4ms to hold some stability). I've set a 3ms delay with 0 INP, which is almost fastpath conditions, to minimise the standard level of trickling CRC errors I get (this has happened on the HG612 as well, so it's not the ASUS device this time thankfully).

I've reset the connection, thought I would as sometimes the instability doesn't occur for a long period of time and other times the instability occurs quickly. We'll see how it continues to perform for the next 2-3 days.

Downstream 80Mbps, 0 INP, 3ms Delay:
Code: 
near-end path0 fec:     19545902(206472339)
near-end path0 crc:     41(826)
near-end fec sec:       9008(106855)
near-end err sec:       13(291)
near-end ses sec:       0(4)
near-end los sec:       0(0)
near-end ua  sec:       0(350)
far-end path0 fec:      946(493770)
far-end path0 crc:      0(1944)
far-end fec sec:        20(8397)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(688)
far-end ua  sec:        0(29623)
outDiscards=2980
inDiscards=1143
outBytes=3411014859
inBytes=264726209
outPkts=37758881
inPkts=38170737
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.1 dB
AttenDown=10.4 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79972 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=19545902
FECUp=946
CRCDown=41
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 2:35, 56 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.8 dbm
PowerUp=4.4 dbm
AttainUp=26123
AttainDown=112356
ShowtimeStart=18
TotalStart=224
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=281
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
 
Last edited:
anyone want to try ...

I assume is better right after reboot (to get best possible rates) to apply the command immediately

All you have to do is, once the modem bootup to open telnet and type in
killall -9 spectrum
DO NOT press rescan at any point if you visit the spectrum page next of traffic monitor ... if you do your connection may mess up again and there is dlm
you loosing the bit tones spectrum but should be much more stable connection

If you try the command after time when your connection is already up - it may not helps as may be affected by the spectrum bug already (users having bad connection) ... it needs right as soon dsl makes connection or even better before right at startup

NOTE if dsl go down for any reason (dc,manually reboot, enable spectrum-rescan etc) will need to reapply the command

@ IXEL
If you test the new beta when you ready still need to kill the process of spectrum, other way will be the same as previous official

I dont know yet if the new beta for bit swap is good but had few crc errors at far end (dslam) and did not passed or appeared to the modem (dsl stats page) with this new beta
 
Last edited:
babis3g said:
anyone want to try ...

I assume is better right after reboot (to get best possible rates) to apply the command immediately

All you have to do guys is once the modem bootup to open telnet and type in
killall -9 spectrum
DO NOT press rescan at any point if you visit the spectrum page next of traffic monitor ... if you do your connection may mess up again and there is dlm
you loosing the bit tones spectrum but should be much more stable connection

If you try the command after time when your connection is already up - it may not helps as may be affected by the spectrum bug ... it needs right as soon dsl makes connection or even better before

NOTE if dsl go down for any reason (dc,manually reboot, enable spectrum-rescan etc) will need to reapply the command

@ IXEL
If you test the new beta when you ready still need to kill the process of spectrum, other way will be the same as previous official

I dont know if if good but had few crc errors at far end (dslam) and did not passed or appeared to the modem (dsl stats page) with this new beta
Click to expand...

Yes, it's best to run that command via telnet before WAN is up, or if necessary as soon as possible after WAN is up. Ideally it's best to kill it before WAN is up though.

I'll be installing the newer firmware later tonight when the internet usage here is quieter - though I'm not expecting it to make much amount of difference as I believe it's the bitswapping for ADSL connections that has been modified. Hopefully I'm wrong though. There might be something else they've changed in that firmware version that they haven't mentioned too.

I've been trying to find a way of either saving custom commands I've run through TC so that they persist between reboots, or to have the killall command run shortly after startup or on a cron job. I've not been successful with either unfortunately.

Final note, at least for my connection, I've not had to re-issue the killall command when I've deliberately dropped my connection. The spectrum process seemed to remain killed.
 
Upgraded to the test/beta firmware 2158. I've also changed the DSL settings so that the connection is T1.413. This means the modem can't automatically sync if for some reason it lost power or had to be restarted, allowing me time to kill spectrum and apply my preferred settings via TC.

Code: 
near-end path0 fec:     1289(1289)
near-end path0 crc:     3(3)
near-end fec sec:       10(10)
near-end err sec:       1(1)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      138(496437)
far-end path0 crc:      0(1944)
far-end fec sec:        1(8437)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(691)
far-end ua  sec:        0(30453)
outDiscards=135
inDiscards=7
outBytes=55641868
inBytes=9366909
outPkts=50762
inPkts=37330
fwVer= FwVer:5.5.1.126_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.7 dB
AttenUp=0.1 dB
DataRateDown=79993 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=1289
FECUp=138
CRCDown=3
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=5 min, 26 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.9 dbm
PowerUp=4.6 dbm
AttainUp=26005
AttainDown=114460
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=289
AdslStandard=VDSL2
AdslType=ANNEX_B

I'll either update this post in an hour, or post a new reply in the morning. Prior to updating I maintained the previous connection without any spikes or instability. I now strongly believe spectrum was the pain in the backside for everyone who owned or owns this device (and most likely for the DSL-N66U as well).

EDIT 1:
The firmware update might've made a further improvement. The FEC usually starts rising rapidly within seconds or minutes of uptime at the current settings, with this firmware it hasn't done so yet.

Code: 
near-end path0 fec:     135101(135101)
near-end path0 crc:     18(18)
near-end fec sec:       280(280)
near-end err sec:       6(6)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      817(497116)
far-end path0 crc:      0(1944)
far-end fec sec:        11(8447)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(691)
far-end ua  sec:        0(30453)
outDiscards=387
inDiscards=58
outBytes=355198608
inBytes=177782155
outPkts=518202
inPkts=349927
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.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79993 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=135101
FECUp=817
CRCDown=18
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 1:51, 53 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.9 dbm
PowerUp=4.6 dbm
AttainUp=26014
AttainDown=114980
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=289
AdslStandard=VDSL2
AdslType=ANNEX_B
 
Last edited:
Hi, are you sure the lower fec at the startup is not because with _2155 did not killall spectrum from the begin before?
Regarding to T1.413 is only for US as far i know
 
babis3g said:
Hi, are you sure the lower fec at the startup is not because with _2155 did not killall spectrum from the begin before?
Regarding to T1.413 is only for US as far i know
Click to expand...

Sadly FEC is rising rapidly again, so that's unresolved. I've selected T1.413 because it doesn't allow the modem to automatically sync on boot up, that means I can then kill spectrum, go through TC and apply my settings and then finally set the connection type to temporarily be VDSL2 via TC - this allows the modem to begin connecting.

Code: 
near-end path0 fec:     26232257(26230305)
near-end path0 crc:     124(97)
near-end fec sec:       12184(12183)
near-end err sec:       30(29)
near-end ses sec:       1(1)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      3037(499336)
far-end path0 crc:      0(1944)
far-end fec sec:        48(8484)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(691)
far-end ua  sec:        0(30453)
outDiscards=494
inDiscards=141
outBytes=1178745666
inBytes=964281414
outPkts=2123755
inPkts=1512840
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.6 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79993 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=26232171
FECUp=3037
CRCDown=124
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 8:46, 37 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.9 dbm
PowerUp=4.6 dbm
AttainUp=26008
AttainDown=114372
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=289
AdslStandard=VDSL2
AdslType=ANNEX_B
 
You must log in or register to reply here.
Back
Top Bottom