Anyone Using an Asus DSL-AC68U

.... So if 10dB prevents fastpath / DLM problems, but wrecks download speeds, then we need to continue working on it - and I'll endeavour to make that happen.

Download speeds will be wrecked, everyone that has tried the 10db suggestion so far has seen a decrease in download speed. This is not a surprise and is exactly how signal to noise margin works.

You basically want as big a difference as possible between attenuation and noise margin for the best speed, without pushing the gap too large as to a point things will not even connect or are unstable. The higher the attenuation number the lower the speed, the lower the noise margin (SNR) the better until it loses stability. (10db will typically give slower line speeds than say 6db, 3db will be even faster than 10db and 6db, but as that figure is nearing zero may be unreliable/unstable)

Asking people to jack up the noise margin to 10db is bad for a number of reasons...

1) By default BTs DLM (This all is for FTTC only) system will aim to try for a 6db noise margin regardless of how good or bad the lines attenuation is initially.
2) If that is not possible (IE a line is unstable) it will then either A) Interleave the line to prevent errors, B) reduce the attainable speed C) Increase the noise margin, typically alterations to noise margin are a last resort.
3) If the device is faulty or to be polite about the Asus device does not function well and you jack the noise margin up to 10db but have a decent 20db attenuation you are going to confuse DLM, it will wonder what the hell is going on, think to itself hmmm a 20db attenuation line should perform well, lead it to think there is some kind of fault and thus it will then first interleave (which will make no difference as you have vastly altered the noise margin) it will then takes its second step and reduce line speeds. If its still unstable it will likely just keep reducing the speed.

NO LINE, I REPEAT NO LINE which is normally capable of over 65(ish)Mb on FTTC should need a 10db margin. The only time it would is if there is a fault or a device can not hold on to noise margin (which is what is happening with the Asus).

I suggest you tell tech department as a start to look at the way bitloading is handled in the firmware, cos all fingers points to that and either the algorithm in general or the bits per tones.

If people set the device to a 10db margin it may well reduce the errors, but that is masking the issue because you are killing a massive amount of line margin in which to do it, which in turn obviously leads to a loss of speed.

Im sorry but if Asus tech department with regards to modems and routers does not understand this, then i politely suggest your company sticks to things they are good at (IE HARDWARE, like monitors and Motherboards) rather than devices that require large amounts of software coding doing complex maths (as is needed in a router/modem firmware).
 
Good thing so far while in usb debug mode i have already had a disconnection. I just happend to download something and notcied my speed was under 1mbps so i checked the router and it just recieved a burst of CRC then disconnected.

To me it is riddiculous to set it to 10db and to stable, its like they are blaming something that isnt the problem, and in turn masking the situation.

Back in school i was taught "Make it a Fair test" this is nowhere near a fair test
however i will do as they ask ruin my profile and proberly get it stuck again.

I think with back up from jim i feel like this will get somewhere.

i encourage all who have given up to try the usb debug for 12 hours and maybe in the coming weeks we will have a stable firmware. the more the better.
 
Good thing so far while in usb debug mode i have already had a disconnection. I just happend to download something and notcied my speed was under 1mbps so i checked the router and it just recieved a burst of CRC then disconnected.

To me it is riddiculous to set it to 10db and to stable, its like they are blaming something that isnt the problem, and in turn masking the situation.

Back in school i was taught "Make it a Fair test" this is nowhere near a fair test
however i will do as they ask ruin my profile and proberly get it stuck again.

I think with back up from jim i feel like this will get somewhere.

i encourage all who have given up to try the usb debug for 12 hours and maybe in the coming weeks we will have a stable firmware. the more the better.

The real issue with the Asus all boils down to DLM, if that was not there you could play with variousSNR/noise figures all you please probably with no further ill effects (apart from obvious reduction in speed when you make the db a bigger figure) With DLM in place it sees this and starts acting like a nagging aunt wondering whats wrong.

Without DLM you could probably leave the device alone and apart from the odd resync suffer no speed loss at all. However even though that is 80% of the story Asus can not completely blame BTs DLM system......

The other 20% of the story is the Asus device obviously in addition to bitloading problems (thats why SNR decays over time) also has issues recording errors and stats relating to them correctly.

The whole issue with the FEC counts (Forward error control) as an example and people seeing Millions of recorded FEC is obviously another flaw, theres no way any line would be seeing Millions of FEC in reality and still for the most part be working (excluding any speed drops or disconnects from the equation). If you were seeing TRUE millions of FEC web sites would be taking an age to load (and by an age i mean literally several minutes or longer) because each time it was loading a bit of data it would have to be corrupt/errored for FEC to step in and correct it....... Obviously though that is not the case. Unless anyone is having to wait stupid amounts of time for a website to load or pinging website results in regular time outs or similar, which i do NOT recall seeing as an issue, which must mean something is amiss in the way the Asus is also collecting stats.

I even think i remember seeing someone on fastpath who was still seeing the device record FEC, how that is even possible i do not know because AFAIK if you are on a true fastpath there is no error control or FEC applied to it.

My advice to Asus is start from the ground up and rewrite huge chunks of the firmware...... Rather than just update driver revisions to certain parts, which from what i can see is all what most of the last half dozen or so firmware updates have been.
 
mine's gone down a little over an hour ago , virtually same time as yesterday , im now down to 28mb and a sync of 29999. Ill keep it on another day or so if it drops again its going in the bin and ill be ringing my isp for their bog standard crap hardware as its miles better than this thing.
 
Apologies - I haven't read all 55 pages of this thread ;-)

I've had a DSL-AC68U for a few months, currently on ADSL and so far it's been okay (not that I've paid any attention to the logs, etc), but the Internet is always "on". Here's the current DSL log:


Code:
DSL Firmware Version	1.0.2.1
DSL Driver Version	FwVer:5.5.1.126_A_A60901 HwVer:T14.F7_0.2
DSL Link Status	up
DSL Uptime	3 days 13 hours 59 minutes 43 seconds
DSL modulation	ITU G.992.5(ADSL2PLUS)
Annex mode	ANNEX_A
SNR Down	7.8 dB
SNR Up	6.6 dB
Line Attenuation Down	22.6 dB
Line Attenuation Up	13.6 dB
Path Mode	FastPath
Data Rate Down	15809 kbps
Data Rate Up	959 kbps
MAX Rate Down	16960
MAX Rate Up	964
POWER Down	0.0 dbm
POWER Up	11.3 dbm
CRC Down	1619
CRC Up	81

However, I've got BT round tomorrow to upgrade me to Infinity !

Was having a dilemma as to whether I stick with the ASUS, or use the BT HH5 I received in the post yesterday. Having read the last few pages, it would seem the HH5 is the best bet for now !

IF I go with the ASUS, do I pay attention to the DSL log page and look at SNR, Path Mode & data rates ?

Thanks.
 
I know Jim has now joined the thread and is reporting info back to Asus but I have been monitoring this thread closely as I have a DSL-AC68U at home and mine has been working fine for the most part. I have had a few days where i have had a lot of disconnects but then it has been solid for weeks. I have been changing my settings to what Paul has advised and submitting feedback data as well. But I have also been changing it back down and trying to tweak the most out of my line.

I am moving to a new house this weekend and have a lovely full 80mbps to play with so I will see what the cheap router from Plusnet says for a week and then install the Asus again and see what happens to my line. Apart from the disconnects I think it is a lovely piece of kit and does everything I need. Guest networks, parental control, great wifi coverage, pass through for my server and VPN. So in the most i am happy with it.

But like some on here I am still not happy the Modem side of things has been resolved and I will be making sure Asus keep working on it.

I will also be testing some of the competition going forward as well as soon as samples arrive so I will be able to offer up some comparisons.
 
I even think i remember seeing someone on fastpath who was still seeing the device record FEC, how that is even possible i do not know because AFAIK if you are on a true fastpath there is no error control or FEC applied to it.

That could be the case if the cabinet they're connected to has G.INP rolled out to it. But for people that have G.INP and the HG612 that shows on a separate bearer in the stats, but it could be displayed as FEC on the ASUS.
 
That could be the case if the cabinet they're connected to has G.INP rolled out to it. But for people that have G.INP and the HG612 that shows on a separate bearer in the stats, but it could be displayed as FEC on the ASUS.

I think that might be the case for me. I was racking up about 2000 CRCs per hour continuously, but very few FECs. Line reported as fast path.

On Monday morning I had a disconnect, and now it has come back up it still reports as fastpath but since then I've had only about 40 CRCs in total over 4 days, but nearly 2000000 FECs reported. I reckon I got put onto G.Inp.

Sync speed is virtually identical to before the drop.

Am tempted to connect my HG612 back up again just to see what that says.
 
Last edited:
So got to setup my fibre tonight, what the best course of action?

Connect Sky hub to phone line, connect ac68u to lab port of Hun and lam port on hub, turn on Ethernet dual wan. Turn on and setup Sky hub? How I'll the ip ranges be handled?

Surely I need to setup the hub first to get an Internet connection and then turn off and connect ac68u? But won't that mess with dlm?

Confused.
 
That could be the case if the cabinet they're connected to has G.INP rolled out to it. But for people that have G.INP and the HG612 that shows on a separate bearer in the stats, but it could be displayed as FEC on the ASUS.

I think this was really early on in the thread (first 10 or so pages, certainly the first half of the thread) before G.INP was even being deployed. Ive not seen a single connection yet that is definitely on G.INP in this thread.

I think that might be the case for me. I was racking up about 2000 CRCs per hour continuously, but very few FECs. Line reported as fast path.

On Monday morning I had a disconnect, and now it has come back up it still reports as fastpath but since then I've had only about 40 CRCs in total over 4 days, but nearly 2000000 FECs reported. I reckon I got put onto G.Inp.

Sync speed is virtually identical to before the drop.

Am tempted to connect my HG612 back up again just to see what that says.

You can check your stats to see if you are on G.INP, look at this post...
http://forums.overclockers.co.uk/showpost.php?p=27735762&postcount=1489
view /tmp/home/root# cat /tmp/adsl/info_adsl.txt
The line NEAR the top titled "Opmode=" will tell you if you are G.INP.
As explained here...
http://forums.overclockers.co.uk/showpost.php?p=27736825&postcount=1491
G.INP will (or rather should) either read G.INP or more likely G.998.4 (The real full name for G.INP. G.INP was only its provisional name)If it states ITU G.993.2 then NOPE you are not on G.INP.

So got to setup my fibre tonight, what the best course of action?

Connect Sky hub to phone line, connect ac68u to lab port of Hun and lam port on hub, turn on Ethernet dual wan. Turn on and setup Sky hub? How I'll the ip ranges be handled?

Surely I need to setup the hub first to get an Internet connection and then turn off and connect ac68u? But won't that mess with dlm?

Confused.

Nevermind, sorted it.

Pioneer i answered all those queries and what you should do first here...
http://forums.overclockers.co.uk/showpost.php?p=27792139&postcount=1603
 
Last edited:
What was I thinking ! I'm getting moved from ADSL to VDSL today - so of course I'm going with the BT HH5 and stick with it for a few weeks.

Then I'll see if there's any progress with the ASUS issue. If not, I'll look to hook up the HH5 as the modem, with the ASUS as the router - I guess that's possible.
 
view /tmp/home/root# cat /tmp/adsl/info_adsl.txt
The line NEAR the top titled "Opmode=" will tell you if you are G.INP.
As explained here...
http://forums.overclockers.co.uk/showpost.php?p=27736825&postcount=1491
G.INP will (or rather should) either read G.INP or more likely G.998.4 (The real full name for G.INP. G.INP was only its provisional name)If it states ITU G.993.2 then NOPE you are not on G.INP.

This is what mine says

lineState=up
Opmode=
SNRMarginDown=5.8 dB

I'm pretty sure it used to say G.993.2

The 'DSL modulation' line in the web UI is also blank now, and has been since the disconnect.

My guess is that I am on G.INP, but yet another firmware bug is reporting it wrongly.

The slight loss in downstream (about 150kb) also implies G.INP I think (According to kitz anyway) as that is borrowed for bearer 1.
 
Last edited:
Since DLM kindly intervened yesterday for whatever reason and added 8ms to both up and downstream and reduced my speeds accordingly, I thought I would go back to the DSL and see what it gets up to.

So running 2187 firmware with all default settings on the DSL side of things.

Anyone want to start a book on how long it's going to take to remove interleaving, if it ever does? :D
 
i decided to change back to my hg612. I will do another usb debug with no settings changed once my line has recovered.

Current stats interleaving on(1471 and on 298)
inp 4 and 2.5
delay 8 and 6
 
This is what mine says

lineState=up
Opmode=
SNRMarginDown=5.8 dB

I'm pretty sure it used to say G.993.2

The 'DSL modulation' line in the web UI is also blank now, and has been since the disconnect.

My guess is that I am on G.INP, but yet another firmware bug is reporting it wrongly.

The slight loss in downstream (about 150kb) also implies G.INP I think (According to kitz anyway) as that is borrowed for bearer 1.

Are you using the device for modem and router duties or just router?

If just router it will report nothing, if using it as a modem and router and its blank thats another new firmware bug, probably to do with the latest xDSL driver they have included. Go back to an older version to check if you want to. G.INP is still not fully rolled out, so it would be interesting to know.

Since DLM kindly intervened yesterday for whatever reason and added 8ms to both up and downstream and reduced my speeds accordingly, I thought I would go back to the DSL and see what it gets up to.

So running 2187 firmware with all default settings on the DSL side of things.

Anyone want to start a book on how long it's going to take to remove interleaving, if it ever does? :D

What do you mean by "I thought I would go back to the DSL" was you using something else as the modem than the Asus? If so i doubt the Asus will remove interleaving at all (dont think ive seen any conclusive post where it has made positive changes) If you mean you have gone back to the ISP supplied gear or Openreach modem then for interleaving to go away, providing the line has no issues it normally will be anything from 3 days to 2 weeks, typically 5-7 days at the most.
 
Last edited:
Are you using the device for modem and router duties or just router?

Modem as well as router. All the other stats are there, just not the Opmode

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

lineState=up
Opmode=
SNRMarginDown=5.9 dB
AttenDown=11.5 dB
SNRMarginUp=8.9 dB
AttenUp=1.6 dB
DataRateDown=66817 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=1854368
FECUp=6754
CRCDown=114
CRCUp=6
HECDown=0
HECUp=0
ADSLUpTime=3 days, 6:38, 14 secs
ADSLActiveTime=0 min, 13 secs
PowerDown=13.1 dbm
PowerUp=6.8 dbm
ATURID=26005443434e0000
ATUCID=b5004244434da44f
AttainUp=25969
AttainDown=84500
ShowtimeStart=13
TotalStart=27
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

Not sure I can bothered to reflash - I may just plug my HG612 in briefly to verify.
 
What do you mean by "I thought I would go back to the DSL" was you using something else as the modem than the Asus? If so i doubt the Asus will remove interleaving at all (dont think ive seen any conclusive post where it has made positive changes) If you mean you have gone back to the ISP supplied gear or Openreach modem then for interleaving to go away, providing the line has no issues it normally will be anything from 3 days to 2 weeks, typically 5-7 days at the most.

Yeah I was on the HG612 lately, and yesterday seemed to have some troubled time in the evening which has eventually led to DLM intervening. No idea why as the HG612 normally holds up quite well.

I'll see what happens with the DSL over the next few days, not too fussed about the additional 16ms as it doesn't appear to stop me winning matches on CoD but would be nice for it to be removed. If after a week there's no change, I'll go back to the HG612 or maybe ECI for complete comptaibility and wait patiently.
 
Sorry for the slight off-topic question but how long does it normally take for DLM to increase speed to full potential?

I had a problem on my line which resulted in 4 consecutive days of re-syncs and my speed dropping from 75Mb to 48Mb and pings increased from 24ms to 49ms.
I left it for 4 weeks so far and it appears my pings are stable at 24ms now but speed is sitting at 62Mb. Zen confirmed that there is still a banding on my line and if I want I can get an engineer out to reset the line but if it stays at 62Mb then I get charged £165+VAT for the privilege.
Should I leave it another month to see if it recovers or take the chance?
 
Back
Top Bottom