Anyone Using an Asus DSL-AC68U

As far as I know only in rt-ac68u they updated firmware with bootloader for increasing space for a partition. They did not make it for other models. I read these on smallnetbuilder.com.
 
Two days into my return to the HH5 and a BT line reset took place this morning bumping up my speed from 61.2Mbps (speed when put back onto the line) up to 69.32Mbps connection speed. Speedtest now shows the line similar to DSL-AC68U speed e.g. 65Mbps.
 
I have just got one of these for testing from Asus what with all the issues with it. I installed it last night and have had a pretty consistent connection since then on Plusnet fibre. Does it take a while for it to start having disconnects. Although it does look like I have had 4 disconnects this morning. only for a few seconds and then it finds the connection again. I will keep checking on the connections throughout the day. The firmware has been uploaded as well to the latest full version. _2155. I am not sure if there is a higher Beta version out there but I will be working with Asus like the rest of you to get the issues fixed.
 
I don't think so, my draytek will update boot loader when they was decided to change it via normal firmware update ... asos looks clearly they have update it & the other units should been affected and the same should valid for drivers ... if the boot loader does not change with asus here you go why some other units may have issues & other may not

EDIT
Unless Asus has not decide to update it yet for all units

They will update boot loader later by time :)
 
I'm performing a new test this morning main difference is that I'm trying a different pilot tone (won't a make difference) and a setting called 'ds_est_new' (ds_estimate_new, this is what might make a difference - who knows, probably won't but I like to play with the internal functionality).

Downstream Configuration
Max/Min Sync Rate: 80,000 Kbps / 0 Kbps
Delay: 1ms (fastpath)
INP: 0
Target SNRM: 9.0 dB

Code:
cur ds_tone_estimate_new_flag on
cur ds_tone_estimate_min_snr_by_power = 3.0 dB
cur ds_tone_estimate_adsl_trend_ratio = 1.  0
cur ds_tone_estimate_echo_thres = -118 dB

Code:
near-end path0 fec:     86(461275888)
near-end path0 crc:     10(3489)
near-end fec sec:       7(212784)
near-end err sec:       7(1080)
near-end ses sec:       0(57)
near-end los sec:       0(0)
near-end ua  sec:       0(218)
far-end path0 fec:      0(360573)
far-end path0 crc:      0(1742)
far-end fec sec:        0(6786)
far-end err sec:        0(1362)
far-end ses sec:        0(0)
far-end los sec:        0(535)
far-end ua  sec:        0(23552)
outDiscards=15
inDiscards=5253
outBytes=1724305271
inBytes=1641686263
outPkts=34673133
inPkts=39227199
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.4 dB
SNRMarginUp=12.4 dB
AttenUp=0.1 dB
DataRateDown=74689 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=86
FECUp=0
CRCDown=10
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=16 min, 23 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=6.4 dbm
AttainUp=29061
AttainDown=88624
ShowtimeStart=19
TotalStart=158
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
 
Last edited:
I have just got one of these for testing from Asus what with all the issues with it. I installed it last night and have had a pretty consistent connection since then on Plusnet fibre. Does it take a while for it to start having disconnects. Although it does look like I have had 4 disconnects this morning. only for a few seconds and then it finds the connection again. I will keep checking on the connections throughout the day. The firmware has been uploaded as well to the latest full version. _2155. I am not sure if there is a higher Beta version out there but I will be working with Asus like the rest of you to get the issues fixed.

I think different people are experiencing different issues with this device.

For me, the connection would stay up but I would get a heap of CRC errors (when on fastpath). For example, the last time I tried with the 2155 firmware there was a burst of 11,000 CRC errors at some point within 25 minutes connection time.

This is random as to when it would happen, but it would happen at some point. I didn't leave it connected this time as I had just got the connection back onto fastpath so reverted back to the OR modem.

The main issue, as I see it, is compatibility with BT's DSLAM implementations and the lack of testing that appears to have been done with UK in mind before the device was released.
 
I have just got one of these for testing from Asus what with all the issues with it. I installed it last night and have had a pretty consistent connection since then on Plusnet fibre. Does it take a while for it to start having disconnects. Although it does look like I have had 4 disconnects this morning. only for a few seconds and then it finds the connection again. I will keep checking on the connections throughout the day. The firmware has been uploaded as well to the latest full version. _2155. I am not sure if there is a higher Beta version out there but I will be working with Asus like the rest of you to get the issues fixed.

The fact that you have had four disconnects in a morning is at the top of the issues. I assume that the Plusnet/BT DLM will kick in having seen those disconnects.

The later firmware (2155 being the latest) seemed more reliable for many of us but not all. the fact that we spend ages pouring over our stats and trying to pull together common themes for people's varying symptoms is something that Asus should have done pre-shipping. I love the functions of the device but the implementation thus far is pretty poor for those of us on FTTC. I don't want to have to check my router many times a day to make sure it isn't going to reduce my line speeds because I will be penalised with DLM.
 
it does look like I have had 4 disconnects this morning. only for a few seconds and then it finds the connection again. .

This is exactly the issues I have with the device. The multiple disconnects cause the BT DLM to very harshly kick in after a day or two and will limit your connection speed. I dont know if Plusnet have the same DLM as the Infinity package but on the HH5 I used to get about 70MB download. With the Asus this was very quickly dropped to 40 before I switched the modem back out for the HH5. Its now been about 4 weeks since I switched back and DLM has only moved me back to 49MB.

The brief disconnections might not be that impacting to some, but I work from home and to have my VPN drop and my work IP phone disconnect multiple times a day randomly just isnt good enough.
 
Test concluded.

After about two to two and a half hours (this time, but seems to be about the average I've noticed) the connection gets a spike of CRC and then seems to have a continuous stream of small CRC errors (similar to the continuous stream of FEC errors, just smaller in comparison). In order to prevent my ES/SES going beyond DLM's threshold I've now returned the connection to INP 1 with a delay of 4ms at 12.0dB SNRM. It's like something goes wrong with the bitswapping algorithm, but surely it can't be that.

Code:
near-end path0 fec:     33812(461280290)
near-end path0 crc:     5839(3825)
near-end fec sec:       218(212932)
near-end err sec:       217(1227)
near-end ses sec:       59(116)
near-end los sec:       0(0)
near-end ua  sec:       0(218)
far-end path0 fec:      29(360602)
far-end path0 crc:      3(1745)
far-end fec sec:        6(6792)
far-end err sec:        3(1365)
far-end ses sec:        0(0)
far-end los sec:        0(535)
far-end ua  sec:        0(23552)
outDiscards=15
inDiscards=5584
outBytes=2162650419
inBytes=2509581985
outPkts=35652634
inPkts=40365350
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.4 dB
SNRMarginUp=12.2 dB
AttenUp=0.1 dB
DataRateDown=74689 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=33812
FECUp=29
CRCDown=5839
CRCUp=3
HECDown=0
HECUp=0
ADSLUpTime= 2:44, 23 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=6.4 dbm
AttainUp=28743
AttainDown=88948
ShowtimeStart=19
TotalStart=158
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
 
Yes I have had a few more disconnects since I looked this morning. I had sent the details to asus and got a quick response on some setting to change. I have made those now and will see how long that lasts. I will run a speedtest when I get home as I dont like doing it via VPN. I will then compare that to ones I have saved with the OR modem and a TP-Link router.

Yes the rest of the settings are really good. will see how many more disconnects I get.
 
Also bear in mind that as DLM kicks in and slows you down the SNR will go from 6 to something like 14 in my case. The line should be a hell of a lot more stable with an SNR like that anyway so isnt necessarily a sign that the settings have helped....
 
This morning I am performing another experiment. I've disabled bitswapping on TX (meaning only the RX/downstream is being bitswapped, which is what needs it the most anyway), and I've also disabled a parameter called 'autobs', unsure what this quite does but thought I'd experiment with it.

I still wonder if there's a flaw in the bitswapping for VDSL2, as usually after around 2 hours the FEC rises rapidly and continuously. On few occasions it has risen before that time. In my previous fastpath experiment I had a similar impact with the CRC's rapidly rising after around two hours of uptime, prior to that they were pretty much the same as what my HG612 has reported in the past when DLM didn't speed band me severely. Something isn't right for sure.

EDIT: Nope, one hour later~ and it's going out of control again.
 
Last edited:
Yes I have had a few more disconnects since I looked this morning. I had sent the details to asus and got a quick response on some setting to change. I have made those now and will see how long that lasts. I will run a speedtest when I get home as I dont like doing it via VPN. I will then compare that to ones I have saved with the OR modem and a TP-Link router.

Yes the rest of the settings are really good. will see how many more disconnects I get.

I think the general experience so far has been that there is no "one size fits all" solution to the instability and the settings that work for you may not work for others. I say "may not" because the science of what causes the instability is not immediately obvious yet.
 
Technically this isn't one size fits all. Though the box may seem to intend that functionality, there are two individual chips with one serving the router functionality and the other serving the modem functionality - which is a good concept ;).

However, in my view there's an obvious pattern here yet ASUS can't seem to either understand that this is abnormal or possibly refuse to acknowledge it as an abnormality by stating that more or less the FEC errors suddenly rising abnormally (and then continuously) after some uptime is normal behaviour (when on interleaved). As I understand it the ADSLx users of this device generally have had few to no problems, it's just the VDSL2 users who are. Those on interleaving don't see the problems either (particularly the case in some parts of Australia as far as I know). Something is happening after a small amount of uptime that either causes the downstream CRC errors to go out of control continuously on fastpath (and eventually leading to a re-sync), or the same effect for the FEC errors on interleaved. Prior to whatever causes this to go out of control, the router seems to perform almost the same (based on error statistics) as my HG612.
 
What's confusing me is how mine can be online with Fastpath for over 10 days, interupted only by me, and have 480709876 FEC's but no disconnects...
 
What's confusing me is how mine can be online with Fastpath for over 10 days, interupted only by me, and have 480709876 FEC's but no disconnects...

Woah, on the ASUS right? EDIT: Oh, the ASUS doesn't report fastpath correctly still. I noticed this when my upstream was put back on fastpath but downstream remained interleaved. Unless both directions are interleaved it doesn't seem to conclude it's interleaved on the statistics page. FEC errors won't cause a disconnection as they are corrected errors. But that's still a heck of a lot of errors corrected.
 
What's confusing me is how mine can be online with Fastpath for over 10 days, interupted only by me, and have 480709876 FEC's but no disconnects...

Your not on fastpath, at least downstream - this line in the stats above is the clue:

InterleaveDepth=1103

For fastpath that should be 1

As Ixel says, the stats page mis-reports the fastpath/interleaved status - looks like if either down or upstream is fastpath, whereas it should either report both individually or if one is interleaved should go with the pessimistic view.
 
After a few changes to the settings mine does seem a little more stable now. I have been using VPN all day and not been knocked off once by it. Only when I rebooted the router was there a drop. I will be checking speed checks later on.
 
After a few changes to the settings mine does seem a little more stable now. I have been using VPN all day and not been knocked off once by it. Only when I rebooted the router was there a drop. I will be checking speed checks later on.

Do you know whether your connection's downstream is interleaved (the statistics display on the web GUI can report fastpath incorrectly however)?

Perhaps if possible post your statistics here so we can see for ourselves, last of all what settings did ASUS recommend you try?
 
Back
Top Bottom