Anyone Using an Asus DSL-AC68U

sumowesley said:
Out of curiosity, in which tool are you executing the stats command? I'm outputing the adsl stats from /tmp/adsl to the console which seems long winded - would be great to have access to the information another way.
Click to expand...

I'm using the TC Console application, disabled tc_diag so I can use it interactively. Please contact me via 'trust' if you want full instructions.

simoncraddock said:
I got punished by DLM again whilst using the Asus on this new firmware, knocking me down 2mbps and increasing the Interleaving depth. Grrrr

One thing I pointed out to Asus which they have so far declined to answer is why my 'Attainable Rate' is almost 20mbps higher using the Asus compared to the 4 other devices I have. My theory is that its this that's causing line instability.

The ZyXel I have is so much more stable albeit at a lower 'Attainable Rate'.
Click to expand...

You could be right there. It's being a bit 'over confident' in what bits it can attain, so is causing more errors than other devices. Perhaps reducing the gain or power equivalent via TC Console will help. I'll look into the possibilities. Obviously AGC hasn't really helped too much being on stable, so I've just set mine to disabled again for the moment.

As one final note, I've observed that the commands I use for forcing downstream sync rate and INP/delay only work/respond/apply while a VDSL2 connection is active. Then once applied you have to re-sync (using the wan adsl close' and 'wan adsl open' or 'wan adsl opencmd vdsl2' or 'wan adsl opencmd multimode').

tribz said:
So this router can let you alter the SNR on the downstream for a higher sync, say a 3dB profile rather than the usual 6? How does the DLM react to that?
Click to expand...

Yes, you can alter the target SNRM via the router's DSL settings page. Alternatively you can alter the maximum and minimum downstream sync rate as well as the INP and delay of the downstream via the TC Console. Contact me for more details if you'd like to do that - I won't share this information on a public forum for obvious reasons.
 
Ixel said:
You could be right there. It's being a bit 'over confident' in what bits it can attain, so is causing more errors than other devices. Perhaps reducing the gain or power equivalent via TC Console will help. I'll look into the possibilities. Obviously AGC hasn't really helped too much being on stable, so I've just set mine to disabled again for the moment.
Click to expand...

I'm wondering if there's a bug in the Asus firmware that is responsible for calculating attainable rate in G993.2 VDSL2 mode.

Does anyone else have a much higher attainable rate compared to the HomeHub5/BTO Modem or any other 3rd party modem?
 
Last edited:
Thanks for the reply - I see the model only supports 2.4GHz Wi-Fi. That's unfortunate as I would really prefer a 5GHz model.

I've converted my DSL-AC68U into just a router connected to my HG612 now while I wait my line to be repaired.

Suddenly developed a line fault yesterday with very loud background noise and the modem resyncing few times an hour BT are attending Monday. Hopefully they can resolve this issue in a single visit unlike last time when I had the same problem 18 months ago. Three visits by Openreach to get them to perform a "lift and shift".
 
Last edited:
StarmanUK said:
Found a single ebay listing with 9 currently available - would you recommend this modem router over the DSL-AC68U?
Click to expand...

It's a trusted well known brand and gets the job done. The GUI may not be the prettiest but it's got more features. I'm guessing it's still a Broadcomm chipset, line stats are very comprehensive unlike the limited Asus stats. I certainly regret buying the asus.
 
Anyone thinking of returning it should have no problems at this early stage in the product life....you could argue that the more people do the more likely that retailers will keep it off the shelves or at least feedback to Asus and put some pressure on.

Currys/PC World service has got a lot better in the last couple of years from my experience, I would think you'd have no bother at all.

If Asus sort out the modem this is still an ideal product for me, but mine went back a few weeks ago, and everything has been stable since. When/if they fix it is a "how long is a piece of string" question, but it doesn't look like it is going to get straightened out quickly.

Either way I think most mainstream dealers would accept it back for refund or relacement with something else - even a few months in.
 
:D

The router works awesomely for me though, was connected @90mb down before lol......
need to order a switch :)
i think this router is best suited to short lines anything in the medium range to long range for get about it and sell it on othe wise your going to be getting connection drops and errors galore.
 
Last edited:
ViRuS2k said:
:D

The router works awesomely for me though, was connected @90mb down before lol......
need to order a switch :)
i think this router is best suited to short lines anything in the medium range to long range for get about it and sell it on othe wise your going to be getting connection drops and errors galore.
Click to expand...

Nice, so you could theoretically go above the package speed limit with this then (though I believe is unwise to as I imagine you'd get caught soon enough lol).

Yeah. Unless ASUS can improve on this (which I don't believe they can), otherwise this would've been a great piece of hardware. Well, I'm just greatful that I can at least get the original downstream speed I near enough had despite the number of FEC's. There's not significant amount of CRC's to disrupt my connection performance though I may try setting INP to 1 on the downstream to see if cuts them down.

Downstream Min/Max Sync Rate 40M/80M; INP 0; Delay 8ms
Code: 
>wan vdsl2 show mgcnt;tcapi get Info_Adsl lineState;tcapi show Info_Adsl
near-end path
0 fec:  122903026(123469570)
near-end path0 crc:     1736(1268)
near-end fec sec:       60714(61270)
near-end err sec:       407(390)
near-end ses sec:       18(18)
near-end los sec:       0(0)
near-end ua  sec:       0(31)
far-end path0 fec:      6118(31219)
far-end path0 crc:      0(1062)
far-end fec sec:        156(2528)
far-end err sec:        0(968)
far-end ses sec:        0(0)
far-end los sec:        0(160)
far-end ua  sec:        0(10332)
up
outDiscards=1426
inDiscards=930
outBytes=1799015405
inBytes=2388865602
outPkts=5314253
inPkts=7084262
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.5 dB
AttenDown=10.4 dB
SNRMarginUp=6.5 dB
AttenUp=0.1 dB
DataRateDown=79991 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=122903190
FECUp=6118
CRCDown=1736
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=19:47, 10 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=4.9 dbm
AttainUp=25342
AttainDown=107232
ShowtimeStart=19
TotalStart=1090
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=424
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

Not sure what to make of the FEC. Still a bit of ES and SES so I will try INP 1 later tonight and see if it cuts that down during the next 24 hours.

If I wasn't overriding the downsteam parameters then I'd be on this:
Code: 
Downstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate                       =  25000 kbit/s
Max_net_data_rate                       =  49000 kbit/s
Rederved_net_data_rate                  =      0 kbit/s
Max_interleaving_delay                  =      8 ms
INP_min                                 =      3 symbols
Dynamic interleaver reconfig(amd1)      = N
INP no erasure                          = N
Pre-emption                             = N
Short packet                            = N
CIpolicy(amd1)                          = Mandatory

Upstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate                       =  10000 kbit/s
Max_net_data_rate                       =  20000 kbit/s
Rederved_net_data_rate                  =      0 kbit/s
Max_interleaving_delay                  =      8 ms
INP_min                                 =      4 symbols
Dynamic interleaver reconfig(amd1)      = N
INP no erasure                          = N
Pre-emption                             = N
Short packet                            = N
CIpolicy(amd1)                          = Mandatory

Haven't found a way of overriding the upstream parameters still, perhaps it's only possible to override the receiving side parameters (e.g. downstream from the modem side).
 
My love/hate relationship with the DSL maybe isn't as clear cut as I thought it was.

With the DSL, I would see thousands of CRC errors in a 24 hour period, but of course you can't see the ES or SES values. In the past few days, with the Billion 8800NL I was seeing similar but a much lower number of ES (say 2000 CRC,150 ES and 10 SES), and I suspect the building works going on nearby is adding REIN / noise to lines in my area (can't prove that though).

So the errors on the DSL aren't necessarily too different to the 8800NL, but they do seem to come along more readily. However, I'm connected to an ECI cabinet and have gone back to the ECI modem and RT-AC68U. I got DLMd as I tested out a couple of things to rule out noise in my house so I'm staying with the ECI modem for the time being to get interleaving removed.

I never suffered from disconnects with the DSL or Billion of late, and never ever never with the ECI modem for months on end.

I think we need to have a details of the cabinet types people are connected to, approx line lengths etc. and their experiences - that's the only way that ASUS can really improve their firmware to cover everyone based on the equipment in use outside their labs.
 
This weekend is probably my last attempt with this box, I'm tired of being a beta tester on what is mostly an expensive ornament at the moment.

I have set the ASUS up with almost the same default settings as my ZyXel box and if it still refuses to be stable it's going back to PC World on Monday.

Settings.jpg


Forgot to mention, I've fitted a shielded RJ11 cable obtained from Maplins this morning.

5mtr Highspeed Shielded RJ11 Data Cable


Update: Uptime 3hrs 10mins = No Errors other than FEC errors due to interleaving.
Update: Dropped connection after roughly 3hrs 40mins.
 
Last edited:
LMFAO
cause of the messing about yesterday i probably reconnected like 3-4 times max and this morning i got stung by the DLM....

JZIrifO.png

auto disconnected me at 8:30 this morning when i was asleep and added interleaving and reduced my download speed by 7meg.

why cant anyone DISABLE THAT CRAP for some users thats what i get for messing with my speeds with the TC console lol guess i will have to wait 10+ days now before its normal again pfft. lol
 
You must log in or register to reply here.
Back
Top Bottom