Anyone Using an Asus DSL-AC68U

Ixel said:
If it remains reasonably stable/has few errors then you could try setting Rx AGC Gain (VDSL) to High Performance, it may well boost your downstream rate (hopefully without increasing the rate of errors). Additionally, what might help slightly, is reducing the Tx Power Offset if you have spare SNRM on the upstream. Remember to keep UPBO enabled as disabling this will result in the downstream attainable rate being reduced due to the increased upstream signal.
Click to expand...

I'll attempt one setting at a time. I've already done two adjustments so far so will wait until tomorrow.
At present, The Rx AGC gain is set to default. My upstream SNR is currently sitting at around 9.5dB. The UPBO setting is sitting in Auto at present.
 
Can anyone help me, I'm trying to setup this router with ASDL (not fibre) but I just can't get it to connect. I've got the link-up but no internet connection.

I used the web to extract the username and password, and have a solid DSL light but no internet light.

I don't kno what to do, any assistance would be greatly appreciated
 
michty_me said:
I'll attempt one setting at a time. I've already done two adjustments so far so will wait until tomorrow.
At present, The Rx AGC gain is set to default. My upstream SNR is currently sitting at around 9.5dB. The UPBO setting is sitting in Auto at present.
Click to expand...

Fair enough. Yeah, I wouldn't do more than two changes every 24 hours either, especially if those changes cause a significant change in SNRM on either downstream or upstream.

Now that I'm actually back on fastpath, I'm going to see what kind of effect changing the Tx Power Offset and such does to the error statistics, but limit my changes to one a day unless it proves for some reason to cause a significant problem.

@Sandmod: What are your VPI and VCI settings? What is your ISP?
 
michty_me said:
I'll make another adjustment tomorrow then. What would you go for first?
Click to expand...

If it was my connection then I'd probably try changing the Tx Power Offset first, adjusting it to -2 and see what kind of effect it has on your attainable rate, SNRM and power dBm (which already is at the highest it can achieve anyway). If it seems better then monitor for errors as usual (though with G.INP this will be masked to some degree).
 
Ixel said:
If it was my connection then I'd probably try changing the Tx Power Offset first, adjusting it to -2 and see what kind of effect it has on your attainable rate, SNRM and power dBm (which already is at the highest it can achieve anyway). If it seems better then monitor for errors as usual (though with G.INP this will be masked to some degree).
Click to expand...

Roger. Will test again tomorrow.
 
Reducing tx power offset to -2 actually made things much worse error wise here. I've just pushed it to +2 to see what effect that has, and so far I'd say it has reduced the number of CRC errors that I would normally get so far on a setting of 0. Will post an update shortly.
 
I think I may have made an important discovery which will most likely be effecting those on fastpath (not interleaved or G.INP, they most likely aren't impacted as much). Particularly those with an actual SNRM pretty close to 6 dB target SNRM.

So far I've noted that if I sync with a target SNRM that is almost equal to the actual SNRM I sync with, I seem to get CRC error spikes and SES occasionally (where CRC's go into the thousands within an hour or so of uptime). If however I sync with a lower target SNRM, e.g. 6 dB, and my actual SNRM is much higher such as 9 dB~ then it seems I don't get the CRC error spikes and my connection performs similar to the HG612 in relation to error statistics.

So, if this is actually the case, the question remains whether or not bitswapping is still not right.
 
One thing I have noticed this evening that setting a target SNR seems to be giving me a heck of a lot more FEC's. In fact, I've already nearly got a quarter of what I had in 12 hours than I did over a whole week.
Not sure if it is related or not. No CRC errors though which is good.

Is everyone using the latest firmware or are people still using the beta that was released with ESNP?
 
Last edited:
Connection has remained stable overnight.

Code: 
>wan vdsl2 show mgcnt
near-end path0 fec:     0(1244059357)
near-end path0 crc:     597(16382)
near-end fec sec:       0(2417417)
near-end err sec:       242(5706)
near-end ses sec:       7(365)
near-end los sec:       0(0)
near-end ua  sec:       0(396)
far-end path0 fec:      134(867672)
far-end path0 crc:      20(7621)
far-end fec sec:        35(26569)
far-end err sec:        19(6649)
far-end ses sec:        0(0)
far-end los sec:        0(1151)
far-end ua  sec:        0(47132)
ADSL uptime : 8:01, 15 secs

I'll continue to monitor it. Target SNRM is set to 5 dB at the moment while the actual SNRM on the downstream is around 10 dB. When this was set to a target SNRM of 9 dB it seemed to cause huge CRC error spikes and CRC errors at more regular intervals. This so far leads me to wonder if bitswapping isn't doing its job correctly when a connection's downstream SNRM is near to or below the target SNRM.

A considerable number of FEC errors on G.INP could indicate a similar problem if the connection was actually on pure fastpath.
 
What I'm away to change to is:

I've disabled all ADSL settings I could.
Stability Adjustment VDSL :5db
TX power control: -1

Just applied those settings now and the results are as follows.

Sync speed increased from 67000kbps to 73500kbps.
SNR down on GUI showing 3.5-4dB.
Max down rate changed from 77500 to 86500.

I'll leave it be over 24hrs and see how I get on error wise. I don't like the look of that SNR. I still think we are flogging a dead horse here.
 
Last edited:
I just tried it again and within 30 minutes I had CRC error spikes as soon as I set the SNRM target to 9dB (close to my current 10dB). I think I'm definitely on to something here. Whilst the target SNRM was less than the actual SNRM (downstream), I'd say by at least 3 dB, it didn't produce the spikes of CRC errors and only the standard small blips I pretty much also get on the HG612.

As such, I'm now back at a setting of 5 dB again. I still think bitswapping might be doing something odd.
 
When I changed stability adjustment to 5db from default (i got an extra 2000 kbps), and a day later changed RX Gain to high performance from default. (got another 2000 kbps)I checked BTW further diagnostics for my profile after each change and there was no increase in my profile. anyone got any ideas why BTW has not done any changes to my profile.
 
I don't think my line is liking this much. It is quite stormy up here today but been on for 9hrs and gained more CRC errors than I had after a week using the standard settings. I'm at 375 after 9.5hrs.
I'm thinking on either just using the WAN port with the HG612 modem for now to see if any further improvements are made to firmware (Which I doubt) or trading it for a dedicated AC router. Which firmware are you using Ixel, The 5007 or still the Beta?
 
Just noticed this thread is still going strong and the problems still persist, which I find quite shocking.

This device has been on the market now for just shy of 12 months and it's still problematic. Some of you guys deserve a medal for perseverance!
 
You must log in or register to reply here.
Back
Top Bottom