Anyone Using an Asus DSL-AC68U

17 hours and going strong on the ESNP firmware.

For those on this firmware, have you guys notice a problem with the "General Log" and "DSL Log" pages locking up the Chrome browser on Android? works fine on the desktop but through a phone or tablet it just locks the whole app up.

I had this a few firmwares back but it seemed to have been fixed on the latest ones
 
PlumpMonkey said:
17 hours and going strong on the ESNP firmware.

For those on this firmware, have you guys notice a problem with the "General Log" and "DSL Log" pages locking up the Chrome browser on Android? works fine on the desktop but through a phone or tablet it just locks the whole app up.

I had this a few firmwares back but it seemed to have been fixed on the latest ones
Click to expand...

Nope, mine seems fine. Stock Android AOSP ROM here on a Xiaomi Mi3W.
 
Ahh its coming back to me. I think it was when the log file got excessively large it caused problems for the phone. I've cleared the log and its working fine again. I used to get a steady stream of upnp errors, but those seem to have gone on this firmware too.
 
babis3g said:
one meg is not really much
however you can try turn off Dynamic line adjustment and enable stability adjustment (adsl) to +2
(administration>dsl settings)
Click to expand...

do you know how to reduce crc errors im on 4 hours uptime with 53 up and 3 down crc errors

i have filtered faceplate fitted and on Sky adsl.
 
Last edited:
Those errors appear pretty low to me.

On my VDSL2 connection at 72M/20M fastpath, with 12 hours uptime so far I've got:
Code: 
near-end path0 fec:     14816
near-end path0 crc:     1990
near-end fec sec:       593
near-end err sec:       589
near-end ses sec:       30
near-end los sec:       0
near-end ua  sec:       0
far-end path0 fec:      219
far-end path0 crc:      30
far-end fec sec:        50
far-end err sec:        26
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0
 
Code: 
tc>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec:     1162215(1407173)
near-end path0 crc:     97(657)
near-end fec sec:       19010(24643)
near-end err sec:       27(29)
near-end ses sec:       0(1)
near-end los sec:       0(0)
near-end ua  sec:       0(226)
far-end path0 fec:      2480(103402)
far-end path0 crc:      0(514)
far-end fec sec:        202(5507)
far-end err sec:        0(178)
far-end ses sec:        0(0)
far-end los sec:        0(499)
far-end ua  sec:        0(19497)
outDiscards=4180
inDiscards=368
outBytes=566084149
inBytes=3155801566
outPkts=30757881
inPkts=71854206
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.8 dB
AttenDown=9.9 dB
SNRMarginUp=6.2 dB
AttenUp=0.1 dB
DataRateDown=62353 kbps
DataRateUp=19000 kbps
WanListMode=0
FECDown=1162215
FECUp=2480
CRCDown=97
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=3 days, 44 min, 10 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.6 dbm
PowerUp=5.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=22090
AttainDown=98716
ShowtimeStart=18
TotalStart=157
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=2652
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
tc>

just wanted to share
 
bitsNbobs said:
ADSL from what i can tell is stable on the device but you have to ensure the settings are correct for it to perform at its best, see some of the earlier posts in the thread by babis3g. who has done a lot of ADSL tests/testing.
Click to expand...

It is anything but stable on some UK ADSL2+ connections that work fine with other combo's. babis3g's experience is not of a UK Adsl2+ connection, (Fixed rate Greece IIRC) so may have no applicability to some of the issues in the UK. Some users, myself included, have tried everything and submitted reports to no avail. Currently on the Asus forum there is also a customer who suggests it has been acknowledged by Asus as a known issue.
 
Elim said:
do you know how to reduce crc errors im on 4 hours uptime with 53 up and 3 down crc errors

i have filtered faceplate fitted and on Sky adsl.
Click to expand...

the errors you have are nothing really for your profile, they are already very low & should not worry ... others having thousands

But if you want to practice once you are close the exchange personal suggestion disable bit swap and see if still lower errors, but really you need to practice your self because each line differ
 
Ygravic said:
It is anything but stable on some UK ADSL2+ connections that work fine with other combo's. babis3g's experience is not of a UK Adsl2+ connection, (Fixed rate Greece IIRC) so may have no applicability to some of the issues in the UK. Some users, myself included, have tried everything and submitted reports to no avail. Currently on the Asus forum there is also a customer who suggests it has been acknowledged by Asus as a known issue.
Click to expand...

Apart my current fixed rate (had not long ago full adsl2+ profile) ... and also when i was with TT back in UK ...
What ever theories from other users will come up ... personal i did not notice any difference really, both are annex A lines ... still about same reaction all my current modems (to noise, errors etc - that time i had the dsl n55u)
of course each isp has his own profile but that is the same been in UK sky/TT / BT etc still their own profile

Yes there is dlm even for adsl in UK ... but for that reason i asked the provider (that time) to lock my profile to snr 9
http://community.talktalk.co.uk/t5/...equest-of-changing-profile/m-p/728112#M348087
so when i was changing my modems (same as now) wont effect me ... & it did not effect me any dlm ( TT had slightly different at that times)

I would advise users with issues to do the same ;)

even with that profile was good enough to test my modems because still some will lock higher rates & some lower ... still will get higher errors or lower depending the sensitivity of each modem

However even with the current high snr target & fixed rate ... i still faced 2-3 disconnections with the dsl68u at heavy rains days with early firmwares ... i have posted a graph long way back in this forum

Now all are fine and i know the reaction of the modem by now for my line... hopefully asus will add similar ESNP - Enhanced Sudden Noise Protection feature and for adsl users
 
Last edited:
Well i have not been able to use this router since i first got it in october due to the issues but now it is working perfectly (touch wood) and it is now running close to what my hh5 (sync wise anyway) so i am now happy (although tbh i still think it is crazy that for 6 months i couldnt use this expensive product)

Below is my current stats and settings
xhhXj0r.png
B6CGrAw.png
4246380691.png


And currently they are rock solid and i am getting no problems and hopefully now it will reset at somepoint and give me a better speed :)
 
Based on your attainable difference with sync rate (significant) and the SNRM for downstream I'd guess that your downstream is interleaved. If so then this unfortunately has a masking effect on the underlying stability issues which occur on fastpath downstream. If DLM eventually changes downstream back to fastpath (assuming I'm right) then you might notice stability problems again. If you do then try the new ESNP firmware.

P.S. Disabling UPBO is against BT Openreach's SIN 498 and causes increased crosstalk for others nearby - not to mention may also reduce your downstream sync rate slightly. I'd strongly advise re-enabling UPBO, and perhaps even reducing the transmit power slightly if you have plenty of spare attainable rate upstream. On mine I reduced mine by '-3' because I have plenty of spare upload speed unused. Reducing transmit power can help increase downstream sync/attainable rate.
 
Last edited:
Ixel said:
Based on your attainable difference with sync rate (significant) and the SNRM for downstream I'd guess that your downstream is interleaved. If so then this unfortunately has a masking effect on the underlying stability issues which occur on fastpath downstream. If DLM eventually changes downstream back to fastpath (assuming I'm right) then you might notice stability problems again. If you do then try the new ESNP firmware.
Click to expand...

This is what would prove if the new firmware was up to fixing the issue. If it doesn't restore from interleaved to fastpath, assuming the connection is stable enough and mine is, then I would think it's a no go...
 
chriscatt said:
This is what would prove if the new firmware was up to fixing the issue. If it doesn't restore from interleaved to fastpath, assuming the connection is stable enough and mine is, then I would think it's a no go...
Click to expand...

Yeah. On mine when I forced fastpath for 24 hours I had no spikes whatsoever, virtually identical results to the HG612. I think ASUS may have resolved the problem. I'm back on DLM's settings for now which will test if FEC errors go abnormally high, so far it's remaining consistent and normal.
 
4.5 hours into the new beta firmware (ESNP)

Code: 
outDiscards=1195
inDiscards=3
outBytes=509730385
inBytes=1696778395
outPkts=944402
inPkts=1378772
fwVer= FwVer:5.5.1.127_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.8 dB
AttenDown=9.3 dB
SNRMarginUp=6.2 dB
AttenUp=0.1 dB
DataRateDown=71509 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=336
FECUp=142
CRCDown=57
CRCUp=25
HECDown=0
HECUp=0
ADSLUpTime= 4:28, 41 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.3 dbm
PowerUp=4.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=20956
AttainDown=85296
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

FEC would normally have been into the millions by now so that certainly much better. Not sure that the CRC values are good or bad given that never had any HH5 stats to compare against. However, huge improvement over the last couple of firmware revisions.

ESNP set to "Stable" btw.
 
Good to hear, glad it's not just me noticing the major improvement. My FEC errors are currently 1/3 that of what I got on the HG612 for a similar uptime. On fastpath (manually forced on test 2), my CRC errors were similar to the HG612 when it was on fastpath.

Here's my stats so far (67M/20M, INP 5/0, delay 16ms/1ms):
Code: 
near-end path0 fec:     163952
near-end path0 crc:     0
near-end fec sec:       1281
near-end err sec:       0
near-end ses sec:       0
near-end los sec:       0
near-end ua  sec:       0
far-end path0 fec:      231
far-end path0 crc:      32
far-end fec sec:        55
far-end err sec:        29
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

fwVer= FwVer:5.5.1.127_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.0 dB
AttenDown=11.4 dB
SNRMarginUp=9.5 dB
AttenUp=0.3 dB
DataRateDown=62681 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=163952
FECUp=231
CRCDown=0
CRCUp=32
HECDown=0
HECUp=0
ADSLUpTime=13:53, 53 secs
ADSLActiveTime=0 min, 20 secs
PowerDown=12.5 dbm
PowerUp=5.5 dbm
AttainUp=26529
AttainDown=101572
ShowtimeStart=20
TotalStart=78
InterleaveDepth=1747
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

EDIT (28/03/2015 22:12 GMT)
Still appears to be fine, no abnormally rising FEC errors.

Code: 
ADSL uptime :19:08, 48 secs
near-end path0 fec:     263785(308177)
near-end path0 crc:     0(2380)
near-end fec sec:       2102(3834)
near-end err sec:       0(1476)
near-end ses sec:       0(37)
near-end los sec:       0(0)
near-end ua  sec:       0(85)
far-end path0 fec:      327(841368)
far-end path0 crc:      45(3969)
far-end fec sec:        81(19991)
far-end err sec:        41(3213)
far-end ses sec:        0(0)
far-end los sec:        0(1111)
far-end ua  sec:        0(46341)

Y8dmeGW.png
 
Last edited:
Switched on G.INP and G.Vector

I have enabled G.INP and G.Vector - it feels like the CRC rate has gone up - there had been around 18 hours of operation with just short of 300 download CRCs reported. Stats since the switch over and my settings are shown below.

The CRC rate is slightly higher although time of day for the running is different so not a direct comparison yet.

5xxecW1.png
 
You must log in or register to reply here.
Back
Top Bottom