Anyone Using an Asus DSL-AC68U

Elim · 26 Mar 2015 at 16:10

so ive just moved over from my sky sagem 2504n to my new asus dsl ac68u (sky adsl unlimited)

a bit disappointing i've lost a full meg on the new asus. Here is the stats difference between the sagem and asus.
anyone know if i can do anything or that's how it is?

Sagem 2504n Log

Asus DSL AC68U Log

babis3g · 26 Mar 2015 at 16:30

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)

bitsNbobs · 26 Mar 2015 at 17:05

Jim - ASUS said:
I have been given a partial explanation, but can't claim to fully understand it! My take right now is to wait for this firmware to come out, and hope that it does solve all of the issues. If not, then we'll carry on working to resolve those that still remain.

At that point, I'll definitely speak to them and see if I can get some information to provide that explains the situation, and I will also discuss the possibility of other affected models and see what is happening to those.

Looking forward to hearing more info and hoping the problems are now solved for users, excellent work Jim

Nice to have a company staff member be so pro-active.

Elim said:
so ive just moved over from my sky sagem 2504n to my new asus dsl ac68u (sky adsl unlimited)

a bit disappointing i've lost a full meg on the new asus. Here is the stats difference between the sagem and asus.
anyone know if i can do anything or that's how it is?

1Mb is nothing you can lose more than that just syncing at different times of the day. Best times to sync are normally 7am to about 2pm. SYncing late at night there is more interference (thats why you can hear all types of foreign radio stations in the wee hours).
I personally would not fiddle with anything, i would not be bothered with such a small loss.

Your noise margin and attenuation figures are very similar to what mine were on ADSL2 and i likewise would sync without tweaking anything between 14 and 17Mb (dependant on time of day, weather etc etc). Your line is running about right.

Ixel · 26 Mar 2015 at 17:18

Test 2 update (from previous post), so far.

Code:

near-end path0 fec:     998(22992)
near-end path0 crc:     119(57)
near-end fec sec:       33(265)
near-end err sec:       28(27)
near-end ses sec:       2(2)
near-end los sec:       0(0)
near-end ua  sec:       0(28)
far-end path0 fec:      2(840476)
far-end path0 crc:      1(3850)
far-end fec sec:        1(19782)
far-end err sec:        1(3103)
far-end ses sec:        0(0)
far-end los sec:        0(1105)
far-end ua  sec:        0(46274)

Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.8 dB
AttenDown=10.2 dB
SNRMarginUp=12.2 dB
AttenUp=0.1 dB
DataRateDown=70967 kbps
DataRateUp=20000 kbps
ADSLUpTime=48 min, 16 secs
PowerDown=12.9 dbm
PowerUp=6.4 dbm
AttainUp=28736
AttainDown=84252
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B

PlumpMonkey · 26 Mar 2015 at 18:22

Installed the Beta FW just now. After running for just over a week on 2187 with only a disconnect every 3 days+ I've had 3 disconnects in the last 24 hours.

Im probably going to get whacked by DLM tonight for that, but lets see if the ESNP makes any difference...

Elim · 26 Mar 2015 at 19:08

bitsNbobs said:
1Mb is nothing you can lose more than that just syncing at different times of the day. Best times to sync are normally 7am to about 2pm. SYncing late at night there is more interference (thats why you can hear all types of foreign radio stations in the wee hours).
I personally would not fiddle with anything, i would not be bothered with such a small loss.

Your noise margin and attenuation figures are very similar to what mine were on ADSL2 and i likewise would sync without tweaking anything between 14 and 17Mb (dependant on time of day, weather etc etc). Your line is running about right.

thanks, looking at the stats its the line attenuation that has gone up

also is 100 crc (up) errors bad for 4 hours uptime?

babis3g · 26 Mar 2015 at 19:23

bitsNbobs said:
Best times to sync are normally 7am to about 2pm. SYncing late at night there is more interference (thats why you can hear all types of foreign radio stations in the wee hours).

When i was in UK with TT the best time for me was anything after midnight till 6-8 am
I guess (not sure) been in a main city street and with many flats around & next of me plus many shops (mainly sweat shops) few pubs,,laundry etc been open till midnight was the reason
Down here in Greece where is not much around is best anything from 6-8 am till evening till the street lights come up

PS (edit)
Did you get new unit after the psu fault?

Ixel · 26 Mar 2015 at 21:26

Continuing on my second test, no loss of sync as yet, errors seem pretty normal when comparing to the HG612 when it once had fastpath in the past.

Code:

ADSL uptime : 4:54, 56 secs
near-end path0 fec:     3112(25106)
near-end path0 crc:     375(313)
near-end fec sec:       236(468)
near-end err sec:       228(227)
near-end ses sec:       2(2)
near-end los sec:       0(0)
near-end ua  sec:       0(28)
far-end path0 fec:      59(840533)
far-end path0 crc:      9(3858)
far-end fec sec:        13(19794)
far-end err sec:        9(3111)
far-end ses sec:        0(0)
far-end los sec:        0(1105)
far-end ua  sec:        0(46274)

I'm hopeful ASUS has cured the stability problems for a good number of VDSL2 fastpath connections. If I can maintain the current trend and connection for 24 hours then I know it's good.

Once I'm done with the tests I've set for myself then I'll probably decrease transmit power as I have plenty of spare upload speed that's unused due to 20Mbps upload speed package limit.

pdes · 26 Mar 2015 at 22:44

Ixel; [code said:
ADSL uptime : 4:54, 56 secs
near-end path0 fec: 3112(25106)
near-end path0 crc: 375(313)
near-end fec sec: 236(468)
near-end err sec: 228(227)
near-end ses sec: 2(2)
near-end los sec: 0(0)
near-end ua sec: 0(28)
far-end path0 fec: 59(840533)
far-end path0 crc: 9(3858)
far-end fec sec: 13(19794)
far-end err sec: 9(3111)
far-end ses sec: 0(0)
far-end los sec: 0(1105)
far-end ua sec: 0(46274)[/code]

How do you get these stats from the DSL 68U? I am using Routerstats and have access to the router but I haven't managed to find out how to get this data.

Thanks

Ixel · 26 Mar 2015 at 22:53

pdes said:
How do you get these stats from the DSL 68U? I am using Routerstats and have access to the router but I haven't managed to find out how to get this data.

Thanks

The only place you can get this information is directly from the modem's operating system. Send me a 'trust' message and I'll email an explaination of what you need to do.

Ygravic · 26 Mar 2015 at 23:39

Jim - ASUS said:
Quick update for everyone:

I've just received a message from the technical team saying that thanks to some recently submitted logs, they have been able to identify a line stability improvement and are currently working to develop it and test it in-house.

Jim do you know if there is any drive to do anything similar about the known ADSL2+ issues which cause line drop outs? I saw a customer on Asus' forum in the last few days saying 'Paul, the ASUS rep. here, has been in touch and suggested that they will look into it' but I have seen nothing proactive from Asus in the way your contribution here has been that suggests any drive to get the data needed to understand and therefore work on the issue.

Regards

Ygravic · 26 Mar 2015 at 23:51

Elim said:
thanks, looking at the stats its the line attenuation that has gone up

also is 100 crc (up) errors bad for 4 hours uptime?

Your downstream vs upstream CRC error ratio is very strange. Did it look remotely similar with your other Modem/router?

bitsNbobs · 27 Mar 2015 at 02:03

Elim said:
thanks, looking at the stats its the line attenuation that has gone up

also is 100 crc (up) errors bad for 4 hours uptime?

Noise margin and attenuation figures canwill vary by a db or so device to device thats nothing unusual. There is nothing wrong with your connection from those stats.

babis3g said:
When i was in UK with TT the best time for me was anything after midnight till 6-8 am
I guess (not sure) been in a main city street and with many flats around & next of me plus many shops (mainly sweat shops) few pubs,,laundry etc been open till midnight was the reason
Down here in Greece where is not much around is best anything from 6-8 am till evening till the street lights come up

PS (edit)
Did you get new unit after the psu fault?

Its the opposite where i live lol i guess its down to experimentation then

NO i got a refund place i bought from messed me around so i got the credit card company involved and my money back. Not sure to buy one again or not.

Ygravic said:
Jim do you know if there is any drive to do anything similar about the known ADSL2+ issues which cause line drop outs? I saw a customer on Asus' forum in the last few days saying 'Paul, the ASUS rep. here, has been in touch and suggested that they will look into it' but I have seen nothing proactive from Asus in the way your contribution here has been that suggests any drive to get the data needed to understand and therefore work on the issue.

Regards

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.

Ygravic said:
Your downstream vs upstream CRC error ratio is very strange. Did it look remotely similar with your other Modem/router?

Theres nothing strange about his stats you can have more errors on the down or upstream. Nothing weird about it at all. Dunno if he can compare to his old device, do sky hubs allow you to see crc figures?

babis3g · 27 Mar 2015 at 06:17

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 seems even for ADSL depending each user line
From many users (ADSL) by disabling everything or just bit swap it does not drop the snr value for a reason

If the line has noise still needs to find the best adjustment for its line

i have seen some one with adsl claiming the settings below are the best for noise line if helps some one

DSL modulation Annex A
Annex mode ADSL2+
Dynamic Line Adjustment (ADSL) Disable
Stability Adjustment (ADSL) 7db
Rx AGC GAIN Adjustment (ADSL) High Performance
Stability Adjustment (VDSL) Disable
Tx Power Control (VDSL) Disable
Rx AGC GAIN Adjustment (VDSL) Default
UPBO - Upstream Power Back Off (VDSL) Auto
ESNP - Enhanced Sudden Noise Protection (VDSL) Stable
SRA (Seamless Rate Adaptation) Enable
Bitswap (ADSL) Disable
Bitswap (VDSL) Enable
VDSL Profile 30a multi mode
G.INP (G.998.4) Disable
G.vector (G.993.5) Disable

Theres nothing strange about his stats you can have more errors on the down or upstream. Nothing weird about it at all. Dunno if he can compare to his old device, do sky hubs allow you to see crc figures?

Click to expand...

currently i have only upstream errors and i know is fine and is because the adsl filter ... if i change it to a belkin has not much upstream errors ... but i let this one because i know is fine and did not bother to change it
(referring to errors and not to my capped high snr target profile at the moment)

1.0.2.3
DSL Driver Version FwVer:5.5.1.127_A_A60901 HwVer:T14.F7_0.1
DSL Link Status
up
DSL Uptime
0 days 14 hours 4 minutes 26 seconds
DSL modulation
ITU G.992.5(ADSL2PLUS)
Annex mode
ANNEX_A
SNR Down
23.7 dB
SNR Up
12.0 dB
Line Attenuation Down
34.5 dB
Line Attenuation Up
14.2 dB
Path Mode
FastPath
Data Rate Down
4094 kbps
Data Rate Up
1023 kbps
MAX Rate Down
14948
MAX Rate Up
1227
POWER Down
18.9 dbm
POWER Up
11.3 dbm
CRC Down
0
CRC Up
42
testing to a far foreign server

ViRuS2k · 27 Mar 2015 at 08:42

Well i wasnt having any issues before and after messing with stuff hahaha i was booted down to a slower speed but just waiting on being kicked back up to 80/20

but so far testing this firmware its 100% better than the previous.
only seem to be getting upload crc errors and thats it.

Ixel · 27 Mar 2015 at 09:16

My second test is concluded. Results similar to the HG612 on similar conditions (fastpath, up to 80Mbps downstream). I think ASUS have resolved the stability problems at last. The only thing I'm slightly curious about is how the ASUS calculates SES, as I'm guessing it's different to how the HG612 calculates them.

Suffice to say, ESNP at 'stable' has a much better result with little impact to my sync rate and SNRM. Didn't have a single CRC spike into the thousands, and my brief testing with interleaving resulted in a stable and consistent FEC error count (which I'll come back to this one and test again).

@babis3g: I don't use IPv6 on the main router anyway, only on my second router on the local network. I can't test this.

RedBull2k · 27 Mar 2015 at 09:19

Im still using the old firmware because asus made changes to it via tc console.

i would normally disconnect before 18hours uptime. as you can see its working brilliantly, 2moro i hope to see a possitive change.

Ixel · 27 Mar 2015 at 09:21

RedBull2k said:
Im still using the old firmware because asus made changes to it via tc console.

i would normally disconnect before 18hours uptime. as you can see its working brilliantly, 2moro i hope to see a possitive change.

Bear in mind that you appear to be interleaved on the downstream, and this has an effect of masking the underlying problem. Only a connection on fastpath can ideally reveal the underlying problem unfortunately.

babis3g · 27 Mar 2015 at 10:05

well guys looks promising then the ESNP from first reports
although personal i am not facing any issues ... I think adsl lines will benefit with something similar

@ Ixel, ok thanks ... don't worry about the other unit, it was only about the dsl68u

RedBull2k · 27 Mar 2015 at 10:29

Yes i agree fastpath needs to be tested on my line.