Anyone Using an Asus DSL-AC68U

Testing different bs_param settings (TC) and so far so good. Had a massive drop in tone around the usual tones that I seem to be effected by and I did get a spike in FEC, and the tone hasn't recovered yet but it's not continually rising by thousands per second.

Early days but might've found a temporary solution, will update later but I expect it'll go wrong sooner or later :P.

EDIT 1:
The initial effected tone did recover a while ago, other tones have fluctuated since then and I've had over 1 hour and 47 minutes of uptime and I've so far had 31,388 FEC errors with 77 FEC seconds on the downstream, all going fine and no continuous FEC by the thousands every second so far. The bitloading isn't having the previous behaviour I described in an earlier post where it seemed to be one step behind in its actions against tones, which I think I may have found the culpret for (and may well have been why errors happened more seriously). If you think about it, having a delayed action of one step behind meant that a further decrease in the bitloading effectively wasn't possible until more SNRM was lost or if SNRM on the effected tone increased (like I was seeing happen, if a tone recovered SNRM then the tone would lose one more bit).

Default bs_param:
Code: 
cur bs trigger snrm diff =  3. 0(dB)
cur bs snr_record_tone_num = 128  bs wait_num = 1
cur bs scan_start_tblidx = 1  bs scan_end_tblidx = 256

My bs_param:
Code: 
cur bs trigger snrm diff =  3. 0(dB)
cur bs snr_record_tone_num = 128  bs wait_num = 0
cur bs scan_start_tblidx = 1  bs scan_end_tblidx = 256

Notice 'bs wait_num', was 1 and is now 0. I believe this is responsible for the delayed action it is currently taking. If I'm right then setting this to 0 means it will not be delayed one step behind in the actions that bitswapping should be taking. Will need more time, I've been fooled a few times by this device (into thinking I've found a solution then later on I find out I haven't).
 
Last edited:
babis3g said:
you been "fooled" because it seems reacts different with each reboot or restart the dsl part :(
Click to expand...

I don't see how I've been fooled? I close and reset the DSL bit everytime I make changes through TC.

Code: 
near-end path0 fec:     265697(736863)
near-end path0 crc:     0(0)
near-end fec sec:       513(866)
near-end err sec:       0(0)
near-end ses sec:       0(19)
near-end los sec:       0(0)
near-end ua  sec:       0(280)
far-end path0 fec:      2334(442785)
far-end path0 crc:      0(1922)
far-end fec sec:        37(7625)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(611)
far-end ua  sec:        0(27829)
outDiscards=14644
inDiscards=13143
outBytes=1490220660
inBytes=1442989926
outPkts=6171017
inPkts=4758626
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.3 dB
AttenDown=10.4 dB
SNRMarginUp=6.6 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=265697
FECUp=2334
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 8:15, 10 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.2 dbm
PowerUp=5.0 dbm
AttainUp=25235
AttainDown=100740
ShowtimeStart=18
TotalStart=37
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

Still looking good, tones are fine too (usual interference on the tones isn't effecting the FEC by continously going up by a thousand or more each second). I will issue another close and reset later if you really think I need to do so.

EDIT 1: As I suspected, it's now gone haywire after around 9 hours of uptime. Tones look ok though this time (assuming it's around 3dB SNR for each bit in a tone, I can't currently see any tone which might be causing the FEC to go wild :(). I'll try fastpath later today but I suspect it'll end up doing something similar.

EDIT 2: On fastpath as of around 11:30am.

Code: 
near-end path0 fec:     0(13928888)
near-end path0 crc:     21(21)
near-end fec sec:       0(5673)
near-end err sec:       11(11)
near-end ses sec:       0(19)
near-end los sec:       0(0)
near-end ua  sec:       0(310)
far-end path0 fec:      653(444415)
far-end path0 crc:      0(1922)
far-end fec sec:        5(7649)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(614)
far-end ua  sec:        0(27855)
outDiscards=0
inDiscards=13147
outBytes=2020704084
inBytes=2727916946
outPkts=7595482
inPkts=6336151
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=15.4 dB
AttenDown=10.4 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=0
FECUp=653
CRCDown=21
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=23 min, 17 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.8 dbm
PowerUp=4.5 dbm
AttainUp=25131
AttainDown=83732
ShowtimeStart=19
TotalStart=56
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

Upstream remains interleaved, but that won't effect my test as it's the downstream which is important. I've also increased the bitswapping sensitivity (changed bs trigger snrm diff from 3.0dB to 0.5dB), so that's the theory anyway, should be interesting to see what happens there. I'm just wondering if the FEC is doing something strange, if so then this test should work without loss of sync, a continuous stream of CRC errors or massive bursts of CRC errors for a considerable amount of uptime.

Here's my current bitloading and snrm graphs:
faDgIVg.png


EDIT 3:
Test concluded. Back to interleaved. I can't resolve this, only possibly delay the instability it seems. I still believe it has to be related to bitswapping. No word from ASUS still.
 
Last edited:
Hi Guys,

Can anyone help out with regards to my speed & DLM?

Up until the beginning of December I've was running Firmware 2072 & was pretty stable. The DSL would stay up for several days on end & resets were few & far between.

At the time my download speeds were about 3.2mbps with the router saying a maximum DL speed of 34999kbps was possible. This is about right for my line & its what I was getting with the Openreach modem.

However, I then installed Firmware 2139 & then the problems started. Speeds dropped off & the DSL line was restarting on an hourly basis, sometimes 4 or 5 resets in a row. Because of the DLM kicking in (on most nights for about a week), my line speed has gone all the way back to 1.9mbps with the router reporting a rate of 17999kbps.

I have now returned my router back to firmware 2072 & I now have a fully stable line (3 days up, no dropouts). However, my download rate is still really poor. Is there a way to force the download rate back up or to kick start DLM so that my download speeds return back to normal.

btw, I'm on Sky Fibre Unlimited 38mbps

Thanks.
 
Last edited:
I think that my theory the daytime disconnects were down to OR performing cabling as mine has now, with a slight download interleave, been up for 8 days. Hopefully at some point it will come back up to full speed at some point...
 
Bad news I guess. ASUS got back to me but they've more or less explained about CRC/FEC, SNRM and summarising how bitswapping works. All this stuff I already know :(, so my email to them may have been useless.

I'm also considering buying myself a used JDSU, but one thing that concerns me is the lack of it mentioning vectoring support on the Infineon chip (onlY Broadcom chip SIM seems to mention vectoring in the product datasheet) - so I may not be buying one if that's really the case.
 
i am sure is something going on there
The asus seems counting too many bit swaps for me (adsl)

take a look at this screen shot (low frequencies due to 4mbps caped profile)
i have emailed to see what will say



Now a billion 7700 (all modems are broadcom except asus) is on for few hrs

NOTE ... i have NO issue with my line with ADSL
 
Last edited:
Ouch, that's awful bitswapping on the ASUS!

Well, clearly there's a flaw in this device (hopefully just the firmware and not the actual hardware design or chipset). My line is fine on two other devices (a HG612 and an ECI /r, one uses a Broadcom chipset and the other uses an Infineon chipset). With the ASUS I get regular drops and CRC errors if my line isn't interleaved heavily enough. Initially my line syncs without noise on the specific tones shown in my previous graphs where I first discovered the possibility of a bitswapping problem, but either minutes or hours later the noise appears and presumably bitswapping goes wrong somewhere (or something is causing the noise to cause the bitswapping).

I am tempted to buy a JDSU to prove to ASUS that my line is fine and it's their device which isn't.
 
I mean to prove for asus should have their own but for our own experience is great idea ... is expensive the JDSU? also the lack of Lantiq infineon makes me thinking as i have a draytek lantiq
 
Last edited:
Great work you guys, make them sit up and listen to you and hopefully, if it's firmware they will fix it but if it's hardware then they should refund or replace us all. What ever happens Asus owe you big time for all this unpaid time.
 
babis3g said:
I mean to prove for asus should have their own but for our own experience is great idea ... is expensive the JDSU? also the lack of Lantiq infineon makes me thinking as i have a draytek lantiq
Click to expand...

Yeah, the JDSU is a tad expensive, however it can act as a DSLAM / VTU-C, which I could then connect the DSL-AC68U to. However I wouldn't have much control over the connection parameters I imagine, probably connect at near full attainable, plus there's no crosstalk so it may not prove a sufficient test for the ASUS in comparison to using my own line. The fact that the Infineon doesn't appear have to have vectoring support will likely mean I won't do this for the price of a JDSU, plus copper testing functionality is useless as remote stuff has to be done to even be able to perform those sort of tests in the first place.

It's frustrating that ASUS aren't currently acknowledging that all of the things mentioned here are by no means normal.
 
Morning ... JDSU look some couple of grands

Got answer for the bit swap & they will look into it ... i mean come on that is a huge difference
The Billion 7700 same bit swap result as the broadcom ones

If i knew how to work the tools with draytek 2830 or 2760 will be good to test ... can not pass the log in page to get the stats to work with the tool
 
babis3g said:
Morning ... JDSU look some couple of grands

Got answer for the bit swap & they will look into it ... i mean come on that is a huge difference
The Billion 7700 same bit swap result as the broadcom ones

If i knew how to work the tools with draytek 2830 or 2760 will be good to test ... can not pass the log in page to get the stats to work with the tool
Click to expand...

There are some cheaper ones going on the famous auction website (used of course). At least you had better luck than I did with ASUS this time. Unfortunately the bitswapping for ADSL is different for VDSL as I understand it on this device, so if they do make changes to the ADSL one then it's unlikely to improve the VDSL side :(.

I'm strongly considering selling mine on the famous auction website after Christmas, unless ASUS change their attitude towards feedback (e.g. instead of giving obvious answers such as changing settings, or providing definitions of things I already fully understand - and not fixing the problem).
 
Yea seems different the bit swap for adsl

I got a new ini file & an updated tc console to test bitswap
lets see
but ask if they will give it you :) tell them i told you

If i was you i was going to keep the ac68u
the wifi is really great especially changing wifi to AU or US and you can use it as pure router adding your isp one or any other you desire such a billion just for the line

When had fibre by TT back in UK, due to dlm (perhaps older system) i prefered having a separate router because some settings changes in the router part (with some routers) may require reboot - so will not reboot & the fibre modem

But that is my opinion
 
Last edited:
babis3g said:
Yea seems different the bot swap for adsl

I got a new ini file for the tc console to test bitswap
lets see
but ask if they will give it you :)

If i was you i was going to keep the ac68u
the wifi is really great especially changing wifi to AU or US and you can use it as pure router adding your isp one or any other you desire such a billion just for the line

When had fibre by TT back in UK, i prefered having a separate router because some changes in the router part (with some routers) may require reboot - so will not reboot & the fibre modem

But that is my opinion
Click to expand...

I see. I expect the ini is for testing ADSL based bitswap, not VDSL. I seriously can't be bothered with wasting anymore of my time with the team at ASUS anymore. I will try all available firmware versions over the next couple of days/week however in order to see how each compares on specific connection settings (e.g. fastpath, up to 80/20, target SNRM 6dB, bitswap on, rx agc stable). Perhaps I'll hit on a version that actually works fine, as chriscatt was saying he was fine on one version, then he upgraded and it all went downhill (I believe).

I already own an RT-AC68U (unused at the moment) which I was going to sell instead, so I doubt I'll need the DSL-AC68U too. There's still some time for me to decide whether to try and auction it or not. I've heard the Fritz!Box 7490 works well, an Infineon chip, sadly I'd lose the customisability that the ASUS has.
 
Last edited:
well the 7490 is a lantiq so ... the tp link 9980 is lantiq (look at kitz are 1-2 treads some users have returned) & some draytek 2860/2760 not going well for all broadcom lines

Here in Greece ( i am right now) lantiq modems works with broadcom exchanges with out really any major issue adsl/vdsl (unless the line is far) because there is not dlm ... i am not saying they are not good devices but some users still facing issues

I would say to get and a broadcom based (can name some but you know them) if you exchange is similar ... but this is my own thinking, i don't mean to to force you ... at least look the zyxel 1312 is good enough & can get it cheap if look around at ebay

If you exchange is infineon then yes the fritz will be great but personal i would keep all modems in my collection :D ..

EDIT
i even still have the hg612 from TT and works really good down here ... in fact i can say is the best i used down here ... i may put it back the next day (after the logs for Asos) for screenshots the bit swaps like the tp link zyxel & billion

i will update tomorrow or next day about my logs

Maybe Asos needs to understand major providers here in Europe use Broadcom or Lantiq :p
 
Last edited:
babis3g said:
well the 7490 is a lantiq so ... the tp link 9980 is lantiq (look at kitz are 1-2 treads some users have returned) & some draytek 2860/2760 not going well for all broadcom lines

Here in Greece ( i am right now) lantiq modems works with broadcom exchanges with out really any major issue adsl/vdsl (unless the line is far) because there is not dlm ... i am not saying they are not good devices but some users still facing issues

I would say to get and a broadcom based (can name some but you know them) if you exchange is similar ... but this is my own thinking, i don't mean to to force you ... at least look the zyxel 1312 is good enough & can get it cheap if look around at ebay

If you exchange is infineon then yes the fritz will be great but personal i would keep all modems in my collection :D

i will update tomorrow or next day about my logs
Click to expand...

I see. Yeah my cabinet's DSLAM is an Infineon. I'll probably order the Fritzbox 7490 after Christmas, might be a nice new year sale or something. All depends on how I do with the firmware. I'm now testing 3.0.0.4.376_2072, the version before they 'fixed VDSL bitswap related issues'. Maybe I'll keep the DSL-AC68U to replace the N66U I currently have running (assuming stability doesn't improve). My current network consists of a DSL-AC68U and an RT-N66U.
 
babis3g said:
i have edit my post up
yea send away the n66u is the same chipset as the ac68u if i am not mistaken
Click to expand...

I see.

Yes, it's possible that they made a mistake in choosing MediaTek as their modem's chipset brand. However, I wonder if ASUS could've still offered identical DSL settings had they chosen either Infineon or Broadcom (e.g. UPBO, tx power, etc.).

Annoyingly I can't seem to get the bitloading and SNRM graphs to show up this time, might require a reboot perhaps (glitched). I am however monitoring statistics on TC and so far they are running similar to the HG612. Interestingly the SNRM on the downstream isn't going upwards like it did on the newer versions (presumably when they claimed to have fixed VDSL bitswap related issues). It has gradually dropped from around an initial 12.5dB to a current value of 11.7dB since showtime (1 hour and 46 minutes ago~). This is similar behaviour that my HG612 does.

EDIT 1:
Also what's interesting is that in this version the adsl diag output via TC is a little more detailed and different.
 
Last edited:
Ixel said:
as chriscatt was saying he was fine on one version, then he upgraded and it all went downhill (I believe).
Click to expand...

No I am ok at the moment on the latest, 2155, firmware. I believe my interleaved download was due to the restarts I had right at the begining of owning this product. At the moment its been up for 9 days and I'm hoping that by the time I get back home after xmas I'll be running fastpath on my downloads again....
 
You must log in or register to reply here.
Back
Top Bottom