Anyone Using an Asus DSL-AC68U

michty_me · 3 Dec 2014 at 15:23

I'm hoping its only 5-10m as they main socket is at the front door and then the computer area is at the top of the stairs directly above really. I hope there isn't any more to pull in.
One thing I know is that I won't be getting the Asus device. I'm still reading of people with issues on the n66u so can't see this being resolved sometime soon. I'll just wait a year or so for some people to take out a reliable unit that has great throughput speeds and WiFi range. This attempt, as good as it sounded, should have been recalled and refunded to everyone.

michty_me · 3 Dec 2014 at 15:25

On another note, I noticed kitz seem to be getting good results from zyxel stuff who use broadcomm chipsets. They are getting higher sync rates than the BT modems and HG612's

danivtec · 3 Dec 2014 at 15:48

michty_me said:
On another note, I noticed kitz seem to be getting good results from zyxel stuff who use broadcomm chipsets. They are getting higher sync rates than the BT modems and HG612's

The Billion 8800 series also uses Broadcom aswell, it just seems to be let down by the internal wireless antennas and is in a similar price range.

However, a 8900 series is slated for release early next year with external antennas.

michty_me · 3 Dec 2014 at 15:56

danivtec said:
The Billion 8800 series also uses Broadcom aswell, it just seems to be let down by the internal wireless antennas and is in a similar price range.

However, a 8900 series is slated for release early next year with external antennas.

Yeah I heard the 8800 were quite good but didn't like the look of it along with the internal antenna. If the 8900 had that then that may be well worth a purchase. Thanks for the heads up on that.
I'll hold off for a while and use my OR stuff for now.

tribz · 3 Dec 2014 at 15:56

Thumbs up for the 8800NL's from me. Not using it for wireless as its not reported to be great but my connection has been rock solid since it replaced my 2860

danivtec · 3 Dec 2014 at 15:58

michty_me said:
Yeah I heard the 8800 were quite good but didn't like the look of it along with the internal antenna. If the 8900 had that then that may be well worth a purchase. Thanks for the heads up on that.
I'll hold off for a while and use my OR stuff for now.

The 8900 is slated for release in early 2015, however it may take a while to get to us if its the same as the 8800 release.

michty_me · 3 Dec 2014 at 16:11

That's good to hear the 8800 is stable.
Not too fussed how long the 8900 takes to come as I'll be out the country for a month at a time and won't need the connection. Gives the firmware and issues a chance to mature.

cuke2u · 3 Dec 2014 at 17:13

Mine has now been up for over nine days with the 2144 f/w...

Ixel · 3 Dec 2014 at 17:15

chriscatt said:
Mine has now been up for over nine days with the 2144 f/w...

Fastpath or interleaved?

danivtec · 3 Dec 2014 at 20:29

Just testing build 2152, crc errors so far seem to be a lot lower than 2144 after a few minutes. Will keep on it.

sga1111 · 3 Dec 2014 at 21:11

Ixel said:
The power supply theory may be worth more investigation. I've put on ferrites on various cables today, including now currently three on the power cable for the DSL-AC68U (with the cable looped round the ferrite once before clipping shut). I'm currently on INP 1 with a delay of 4ms and I'm currently barely getting any error seconds, at best an average of 6 an hour. In the past when I've tested this at up to 80Mbps I've found myself getting a regular amount of CRC's even on a low INP and low delay configuration.

FEC's are still through the roof but Paul Lee says, to more or less summarise what he said, basically to ignore it as it's just errors being corrected (or FEC showing it's working) and won't effect performance (though I realise that bit obviously).

If this continues I will dare the test of fastpath again.

I've seen improvements, big ones, just doing as you have, 3 worked for me. So it's interesting to find you've seen similar.

Ixel · 3 Dec 2014 at 22:56

sga1111 said:
I've seen improvements, big ones, just doing as you have, 3 worked for me. So it's interesting to find you've seen similar.

Another thing I've noticed is that, at least from here anyway, is that the ASUS doesn't initially start producing more errors until some hours into the connection. Also the SNRM seems to gradually rise around +1dB on the downstream after some hours of uptime, no matter whether I synced during the night or during the day. Bitswapping still hit and miss possibly?

babis3g · 4 Dec 2014 at 00:31

Ixel said:
Bitswapping still hit and miss possibly?

i think it does (firmware 2144-2152) perhaps erlier
Turn off just bit swap adsl/vdsl & sra, nothing to loose once you testing so many different features
I bet you will have less errors and believe me bit swap still working even if is off

With adsl when i enable bit swap & sra it drops the snr by time ... not sure if is the same with vdsl ... maybe some one can try?

Ixel · 4 Dec 2014 at 01:37

babis3g said:
i think it does (firmware 2144-2152) perhaps erlier
Turn off just bit swap adsl/vdsl & sra, nothing to loose once you testing so many different features
I bet you will have less errors and believe me bit swap still working even if is off

With adsl when i enable bit swap & sra it drops the snr by time ... not sure if is the same with vdsl ... maybe some one can try?

Disabling bitswap made me lose sync within minutes on fastpath, considerably worse results unfortunately (might not be ideal for VDSL2 connections).

Instead I'm trying a modification or two to the bitswap algorithm, or so I believe anyway. The default bitswap SNRM difference is +/- 3.0dB, I've reduced this to +/- 2.0dB, I may also try 1.0dB or 1.5dB. This is assuming what I'm modifying is actually what I think it is.

babis3g · 4 Dec 2014 at 06:41

Ixel said:
Disabling bitswap made me lose sync within minutes on fastpath, considerably worse results unfortunately (might not be ideal for VDSL2 connections).

Instead I'm trying a modification or two to the bitswap algorithm, or so I believe anyway. The default bitswap SNRM difference is +/- 3.0dB, I've reduced this to +/- 2.0dB, I may also try 1.0dB or 1.5dB. This is assuming what I'm modifying is actually what I think it is.

ohhh ok, thanks for your time, i appreciate

cuke2u · 4 Dec 2014 at 08:39

Ixel said:
Fastpath or interleaved?

Fastpath but on a 40mb connection..

Ixel · 4 Dec 2014 at 08:48

chriscatt said:
Fastpath but on a 40mb connection..

I see, fair enough.

Well, from last night when I applied the bitswap changes (bitswap SNRM difference from 3.0dB to 1.0dB +/-), current observations are that the connection has held up so far and hasn't had noticeable CRC spikes (an average of less than 10 CRC errors per error second). I have bumped my SNRM target up to 9dB as well, but usually I would encounter a loss of sync or more errors by now. I'll leave it running unless I notice instability or large amounts of error seconds in a short time. Once again I have noticed that more error seconds are occurring during daylight than night time.

Conclusion, possibly another improvement, and if so then the bitswapping setup may still be a bit less than optimal.

Fastpath, up to 80Mbps @ 9dB SNRM:

Code:

>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec:     60954(304794340)
near-end path0 crc:     3218(6988)
near-end fec sec:       410(155049)
near-end err sec:       378(2416)
near-end ses sec:       19(107)
near-end los sec:       0(0)
near-end ua  sec:       0(543)
far-end path0 fec:      136(357855)
far-end path0 crc:      15(1440)
far-end fec sec:        37(6268)
far-end err sec:        13(1079)
far-end ses sec:        0(0)
far-end los sec:        0(472)
far-end ua  sec:        0(20289)
outDiscards=1255
inDiscards=78106
outBytes=1154702471
inBytes=1720563088
outPkts=37205287
inPkts=45203555
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.4 dB
SNRMarginUp=6.5 dB
AttenUp=2.3 dB
DataRateDown=75736 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=60954
FECUp=136
CRCDown=3218
CRCUp=15
HECDown=0
HECUp=0
ADSLUpTime= 6:29, 54 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=5.6 dbm
AttainUp=22463
AttainDown=91812
ShowtimeStart=19
TotalStart=1070
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

sga1111 · 4 Dec 2014 at 09:54

Ixel said:
Another thing I've noticed is that, at least from here anyway, is that the ASUS doesn't initially start producing more errors until some hours into the connection. Also the SNRM seems to gradually rise around +1dB on the downstream after some hours of uptime, no matter whether I synced during the night or during the day. Bitswapping still hit and miss possibly?

Yes I've found that to, I think this is a collection of issues not just one. I think the bitswap is a problem to consider. I turned most things off and it lasted longer in sync.

Edit:
I've sent my unit back for a replacement, just as I've sent it back Paul Lee has asked for pictures on how I've set up the ferrite's etc typical! Now they are listening on the power adaptor front, that's a bonus! I think he struggles with understanding some of what we're trying to say as he needs a lot of clarification. I will sort that on return of a new or repaired unit

trisp · 4 Dec 2014 at 14:24

Looks like there is a new firmware floating around (the current new one has been deactivated on the website)

ASUS DSL-AC68U Firmware version 3.0.0.4.376_2155 (This product supports both Annex A and Annex B)
1. DSL firmware updated - v1.0.2.1.
2. DSL driver updated - v5.5.1.126.
3. Fixed WAN Connection Type - PPPoA related issues.
4. Fixed previous firmware v3.0.0.4.376_2139 Annex mode - Annex B/J/M failed to sync issue.
5. Annex B/J/M option now replaced with Annex B/J mode.
6. Fixed Advanced Settings > Administration > DSL Setting, changes failed to take effect in certain case issue.
7. Fixed various UI related issues.
8. Fine tune Feedback feature.
9. Fixed Diagnostic debug log failed to transmit in certain case issue.
10. Fixed DSL modulation - G.dmt, DSL Log > SNR Down invalid in certain case issue.

http://dlcdnet.asus.com/pub/ASUS/wireless/DSL-AC68U/FW_DSL_AC68U_30043762155.zip

Ixel · 4 Dec 2014 at 14:26

trisp said:
Looks like there is a new firmware floating around (the current new one has been deactivated on the website)

ASUS DSL-AC68U Firmware version 3.0.0.4.376_2155 (This product supports both Annex A and Annex B)
1. DSL firmware updated - v1.0.2.1.
2. DSL driver updated - v5.5.1.126.
3. Fixed WAN Connection Type - PPPoA related issues.
4. Fixed previous firmware v3.0.0.4.376_2139 Annex mode - Annex B/J/M failed to sync issue.
5. Annex B/J/M option now replaced with Annex B/J mode.
6. Fixed Advanced Settings > Administration > DSL Setting, changes failed to take effect in certain case issue.
7. Fixed various UI related issues.
8. Fine tune Feedback feature.
9. Fixed Diagnostic debug log failed to transmit in certain case issue.
10. Fixed DSL modulation - G.dmt, DSL Log > SNR Down invalid in certain case issue.

http://dlcdnet.asus.com/pub/ASUS/wireless/DSL-AC68U/FW_DSL_AC68U_30043762155.zip

Nice find. I see they've updated both the DSL driver and firmware in this one, I wonder what they've changed. Hopefully the rumour of them locking TC down isn't true for this version.