Anyone Using an Asus DSL-AC68U

Ixel · 15 Dec 2014 at 16:32

I can definitely confirm now that when a tone (or some tones) has their SNRM drop a considerable amount of dB that this triggers the wild FEC count. ASUS needs to do something to fix this handling (presumably relating to bitswapping still).

See the below screenshot, look at where the arrow is pointing to. Initially this was normal on the graph, a minute or so later I observed it suddenly dive along with the bitloading for that tone (or some tones). However, despite the drop in bitloading for the tone (or some tones) that had the SNRM drop, I guess it's not enough to prevent FEC going wild (I imagine if I wasn't interleaved this would result in lots of CRC errors or a loss of sync).

EDIT 1:
The tone/tones have recovered, see the following screenshot. I can also confirm the FEC has stopped rising astronomically every second too. So yes, it's related to how this device is handling bitloading it seems, but I don't know if ASUS will listen (as they've said that an abnormally high FEC count, in comparison to other devices I've used particularly, is normal), but I also now believe this is the reason why fastpath connections lose sync regularly or have a high CRC error count.

babis3g · 15 Dec 2014 at 16:35

Ixel said:
I can definitely confirm now that when a tone (or some tones) has their SNRM drop a considerable amount of dB that this triggers the wild FEC count. The question is how to fix it, or whether ASUS needs to do something to fix this handling (presumably bitswapping).

See the below screenshot, look at where the arrow is pointing to. Initially this was normal on the graph, a minute or so later I observed it suddenly dive along with the bitloading for that tone (or some tones). However, despite the drop in bitloading for the tone (or some tones) that had the SNRM drop, I guess it's not enough to prevent FEC going wild (I imagine if I wasn't interleaved this would result in lots of CRC errors or a loss of sync).

send email to Asus

Ixel · 15 Dec 2014 at 16:38

babis3g said:
send email to Asus

Alright, I'll give it a try but I'm just expecting to be told that it's normal behavior for the FEC to do this

(as if I'm some novice user lol).

EDIT: Emailed Paul Lee at ASUS. Will reply here with conclusion once I have feedback. I'm glad I may have truly found the problem causing those of us effected the errors/loss of syncs.

Evil Shubunkin · 15 Dec 2014 at 17:08

So what happens if you disable bitswapping in the GUI? I wonder if this would prevent the FEC spikes?

Ixel · 15 Dec 2014 at 17:10

Evil Shubunkin said:
So what happens if you disable bitswapping in the GUI? I wonder if this would prevent the FEC spikes?

I've tried that and unfortunately it makes matters much worse. Presumably when a tone (or tones) lose their SNRM by a considerable amount of dB without bitswapping the bitloading remains at the original level for the effected tone/tones. Effectively this means (multiple times) more errors.

I also notice that, comparing the two above screenshots, when the tone/tones effected by the arrow recovered, the bitloading dropped one more rather than go back up or stay at the previous level. Perhaps the tone/tones dropped a bit more than in 'screenshot 1', or perhaps the bitswapping algorithm is still flawed for VDSL2 connections. Clearly it has to be related to the way bitloading is handled presumably by bitswapping.

babis3g · 15 Dec 2014 at 17:13

with adsl line
If i disable reduced usb 3.0 it has some small negative effect to bit swap
I have email them as well

Apart that with my adsl line, bit swap seems works better with turned off because it keeps the snr more stable (even if crc errors may appear) , i have mentioned previous post way back & i have emailed but hope they will look into it again

I also think something is going on with bit swapping

Ixel · 15 Dec 2014 at 17:19

What's frustrating is that it's only a particularly small range of tones which seem to be seriously effected in this way, so if I could make them unusable then that could be at least a temporary solution until ASUS can resolve it. Well, for now the only solution is to remain interleaved although it's just masking the problem.

cuke2u · 15 Dec 2014 at 18:24

It's hit and miss. Improvements appear to be being made at the moment with each firmware release, but there are still some people having issues with this device when it's on a fastpath connection (stable on interleaved)

I thought there were as many having problems even when they're on interleaved from what I've read...

Evil Shubunkin · 15 Dec 2014 at 19:36

chriscatt said:
I thought there were as many having problems even when they're on interleaved from what I've read...

My issue being on interleaved was the number of FEC and whether or not that would cause DLM to consider the line too instable to revert to fastpath. The connection was fine, no disconnects.

I didn't really have any disconnects when I was on fastpath and getting CRC bursts, but I didn't leave it long enough for DLM to intervene (or so I thought, but ended up interleaved a couple of times).

Ixel · 15 Dec 2014 at 19:38

Evil Shubunkin said:
My issue being on interleaved was the number of FEC and whether or not that would cause DLM to consider the line too instable to revert to fastpath. The connection was fine, no disconnects.

I didn't really have any disconnects when I was on fastpath and getting CRC bursts, but I didn't leave it long enough for DLM to intervene (or so I thought, but ended up interleaved a couple of times).

I see. Yeah the problem with interleaved is that it's masking the underlying problem, which appears from my observations to be the way the device is handling tones that lose a reasonable amount of SNRM compared to initial SNRM at showtime. It will be interesting to see what ASUS say, if they do.

EDIT: I've just seen it again. The bitloading and SNRM graph. After a tone recovered the bitloading on the bad tone reduced by one bit further. Perhaps this is what it's meant to be doing while the tone is bad, not after it recovers? As it's not, the tone produces errors due to an insufficient SNRM for the current bitloading on that tone?

babis3g · 16 Dec 2014 at 08:37

I think you have spot it (at least one major issue)
With mine if i disable reduced usb 3.0 the bit swap seems more valuable (adsl) but i am not using the tc console to confirm for sending it to asus
Perhaps if you record it (once you using the tc console) the bit swap with reduced usb 3.0 disable be more valuable and to you?

Sorry for making you "exercises" but i also think something wrong in there ... to me (i could be wrong) asus seems is not using the bit swap from mediatek but its own one

Ixel · 16 Dec 2014 at 09:11

Well, no reply from them yet (usually they've replied to me the following morning) but they might be busy. If they don't acknowledge by the end of the week then I might do the video recording as you suggested - so they can see it happen for themselves. If I could get my hands on the original MediaTek firmware then I would try it, but I suspect this firmware has been modified to work with the 'dual chipset' model so would probably prove useless to be tested. Obviously the tclinux.bin could be uploaded via the internal IP when enabling access by using the adslate command on telnet.

babis3g · 16 Dec 2014 at 09:25

I am sure they're looking into it

... lets wait what will say about it

MikeBee · 16 Dec 2014 at 09:45

Thanks all. I may keep the OR modem then and go with a replacement router with WAN port. I was hoping for an all in one solution with excellent range, but there just doesn't seem to be a good solution yet (apart from the Fritzbox which is $$$$).

babis3g · 16 Dec 2014 at 10:16

MikeBee said:
Thanks all. I may keep the OR modem then and go with a replacement router with WAN port. I was hoping for an all in one solution with excellent range, but there just doesn't seem to be a good solution yet (apart from the Fritzbox which is $$$$).

the ac68u has really good wifi range and can adjust a Lan port into incoming wan port in the case xdsl is not working good

for the wifi see here
http://forums.overclockers.co.uk/showpost.php?p=27331689&postcount=757
wl country US or AU has increased the wifi dramatic

I am getting here in a village (ac68u placed) in a room with double glazing window & aluminium net for mosquitoes (outside of window), then garden, then other room build with concrete bricks about 10 meters away (inside the other room) 60-100% signal via this method with a mobi in most places ... & with laptop almost 100% everywhere (2.4 G)

EDIT
But this is my personal opinion about the ac68u

trisp · 16 Dec 2014 at 16:56

babis3g said:
I am sure they're looking into it ... lets wait what will say about it

One of ocuk staff has been given one to test and posted that he was having problem's :rolleyes:

And that he would get back to us i think that was a few days ago so hopefully he will have better luck then we are having

I am currently using mine as a christmas decoration

Ixel · 16 Dec 2014 at 17:26

trisp said:
One of ocuk staff has been given one to test and posted that he was having problem's

And that he would get back to us i think that was a few days ago so hopefully he will have better luck then we are having

I am currently using mine as a christmas decoration

I had thought of using mine as a doorstop, a very expensive doorstop. ASUS haven't replied to me, somehow I don't think they will either :/. If ASUS choose to ignore the information I've sent them, or at least fail to acknowledge it in the very least, then I might consider avoiding ASUS for any device in future. It's ironic, most of my products here are at the moment of ASUS branding and they all work superb except for the DSL-AC68U.

cuke2u · 16 Dec 2014 at 17:50

To boycott asus just because of one 'bad egg' would just mean you miss out on the excellent motherboards they produce. At the end of the day it's your money but I think you'd be silly.

babis3g · 16 Dec 2014 at 18:01

Ixel said:
ASUS haven't replied to me, somehow I don't think they will either :/. If ASUS choose to ignore the information I've sent them, or at least fail to acknowledge it in the very least, then I might consider avoiding ASUS for any device in future. It's ironic, most of my products here are at the moment of ASUS branding and they all work superb except for the DSL-AC68U.

i am sure they looking into it, perhaps they testing if they find same issue & i am sure they will come back to you with good or bad news ... be patient

Ixel · 16 Dec 2014 at 18:18

babis3g said:
i am sure they looking into it, perhaps they testing if they find same issue & i am sure they will come back to you with good or bad news ... be patient

Yeah, I'll be patient and live in hope

.