Anyone Using an Asus DSL-AC68U

ViRuS2k said:
Becuse the ASUS does not have a broadcom chipset. and broadcom chipsets love long lines or unstable long lines.

ASUS is using the Mediatek chipset, most suited to short lines.
also there is a combination of what equipment is in your exchange/cab that can work perfect out of the box with the router your using or require firmware optimization like the asus needs.
Click to expand...

I'm close to my FTTC cabinet (i.e. short line) - I can see it from my front door. I'm on business infinity 1 (2 is not available) and am close (up& down) to the maximum possible speed (using an OR modem).

Not arguing about the chipset (don't have the knowledge) - but in my case it wasn't (ac68u has been returned) not a line length issue.
 
I've designed an app in C#.NET which will now graph the errors and other statistics from the modem (on a 24 hour chart, updated once a minute, while data is fetched from the DSL-AC68U every 10 seconds). If it proves stable and reliable enough then I'll release it for those curious who wish to do the same.

I'm mainly doing it to see if there's any pattern to my errors, especially when I receive rare spikes of CRC's.

Interestingly my attainable downstream is higher again at the moment (was around 93.5Mbps after I lost sync at 2am), now showing 95Mbps~.
 
plaistowpaul said:
I'm close to my FTTC cabinet (i.e. short line) - I can see it from my front door. I'm on business infinity 1 (2 is not available) and am close (up& down) to the maximum possible speed (using an OR modem).

Not arguing about the chipset (don't have the knowledge) - but in my case it wasn't (ac68u has been returned) not a line length issue.
Click to expand...

Also remember, its also not about how close a cab is to your house though that is a rough idea but, as your line may go from that cab quite a distance then arc off into little phone posts then arc off there to other properties before arcing back into your house.

so sometimes a cab being close to a house means nothing as the line length from that cab may be 5-10 times the longer in length..... also depending on how old the house is. or when the phone line was installed.
 
Last edited:
I couldn't say about any of that to be honest, but I get close to max thoeretical speeds up and down with the OR modem and with the HH5 - which says to me the run isn't far and/or the cabling is OK.

Been running weeks on end now (not hours or days) with the OR modem and not a blip. Been running a program called "Internet Connectivity Moitor" from my server that pings google and yahoo every 5 seconds - not skipped a beat.

Not doubting that cable runs/distance/quality affect performance, but I don't think any of those was the issue for me - take away the DSL-AC68U - take away the problem.
 
Last edited:
the point im trying to get across, not all lines work well with broadcom or mediatek chipsets.

what works for one, probably will not for another. without some optimizations or tweaks that is.
 
I am about 2716m away from my exchange, the nearest cabinet is about 400m away. Over fours days up now, as far as I am concerned there seems to be so many variations in performance of this hardware it is very sensitive to something. I had over 19,000 crc's within a short time when I first booted up this thing now I have only 199 down and 0 up after 4 days and 5 hours having changed nothing in the settings, all is at default. If it was the chipset causing the problem I think everyones entitled to a refund under the terms of not fit for the purpose and asus should withdraw the product and think again. However something tells me, and maybe from my experience with this hardware, that it isn't that simple.
 
Ixel said:
I've designed an app in C#.NET which will now graph the errors and other statistics from the modem (on a 24 hour chart, updated once a minute, while data is fetched from the DSL-AC68U every 10 seconds). If it proves stable and reliable enough then I'll release it for those curious who wish to do the same.

I'm mainly doing it to see if there's any pattern to my errors, especially when I receive rare spikes of CRC's.

Interestingly my attainable downstream is higher again at the moment (was around 93.5Mbps after I lost sync at 2am), now showing 95Mbps~.
Click to expand...

That would be a very useful app, is it android based or just windows, sorry don't know what c# net is...
 
chriscatt said:
That would be a very useful app, is it android based or just windows, sorry don't know what c# net is...
Click to expand...

It's Windows. Later today I'll post some graphs it has made so far, I'll release it soon - just need to be sure there are no bugs in the code.
 
Last edited:
chriscatt said:
"does anyone know exactly how meny crc errors in a day your allowed before dlm triggers are speed reduction or latency reduction ????
or if you switch off your router how meny times before DLM links your line is faulty and reduces your speed"

Anyone?
Click to expand...

Zen state it to be the following:
DilxTBs.png

From my DLM experiences, I would say that the 'speed' profile matches pretty much the experiences I've had so far (Zen supply FTTC with 'speed' profile by default).

It's not based on CRC's, it's more to do with the ES (error seconds, shown above as MTBE). So if you're on the speed profile then it would be no more than 2 ES per minute (2880 ES per day). However, DLM may take other factors into consideration, e.g. resyncs combined with error seconds, FEC count, variations in line conditions, history. If your connection hasn't been synced for an entire day then it will normalise this.
 
Last edited:
I installed the test firmware a few hours ago and its looking much, much better. I'm getting on average just under 1 CRC error a minute which I think will be fine whereas before I was getting 20,000+ every hour or so. I've not had any resyncs during this time which is far better than before as it would reset frequently.

The sync rate was actually about 5MB higher than where the HH5 was before the modem swap out and the max up/down are about 20/10 MB higher than what the HH5 said was possible.

Fingers crossed they fixed it....

ILGIJfi.jpg
 
adhTbOu.png

about the norm for my line i think im free from the dlm intervention with these stats, just hope it stays that way...

those that have tried the beta firmware does it actually improve anything or is it worth me giving it a try to reduce crc`s even further ???
 
So after running the test firmware for 24 hours I've had six resyncs, one of which I think was DLM related and its dropped my sync rate by 10MB again. I've submitted some feedback to ASUS and will be going back to the HomeHub5 again until they can do something about this.
 
Interesting. While I've managed to avoid multiple re-syncs, the damage is already done by the previous firmware (1.0.1.7) with DLM capping me from 74/20 to 49/15. I'm still getting a trickle of CRC errors, enough to keep me above the 'good' DLM threshold that's mentioned in Zen's FTTC training doc unfortunately, so I suspect I'll be stuck on 49/15 for quite a while unless the ECI /r (when I plug it back in eventually) can keep it below that threshold to restore a higher sync speed.

I'm trying other tweaks as well, such as reducing the transmit power, in order to try and reduce the CRC errors. On an interesting note I believe I've noticed a pattern that more errors seem to occur during daylight hours, typically from around 7am to 5-6pm, while the evening hours have less occurrence of errors. I'll post some graphs later tomorrow, as I'm still developing the app and haven't quite got things the way I want on the graphs just yet.
 
When I got dropped to 49/15 from an initial 72/20 on the 1.0.1.7 firmware it took over 10 days of using the home hub to get DLM to forgive me enough to put it back to the initial rate. I think it was 8 days before it did anything, and then about another 3 before did the final bump up.
 
I think instead of going through a third party a technical representative from asus should be contributing here as it is clear that the beta firmware isn't having the result that all those with issues should expect...
 
The guys at Asus do know of the issues you guys are having and are working with the forum members to fix the issues. Below is email feedback from Paul Lee at Asus.

"Actually we have been receiving feedback from UK customers on daily basis.

Noticed Overclockers forum active user simoncraddock posted some comments, we have been looking at the debug logs that Simon captured for us earlier, seems like with the latest xDSL driver version 5.5.1.124 which included in latest firmware v3.0.0.4.376_2072 Bitswap algorithm has some issues, which in certain cases might leads to interruptions.

Hence solution is go to Advanced Settings > Administration > DSL Setting and configure with the following, see whether line could be stabilized. This change specifically for the Fibre service(VDSL2), updated firmware that could address this issue will be released this week.

- Set "Rx AGC GAIN Adjustment (VDSL)" to Stable.

- Set "Bitswap" to Disabled.

- Set "Improved Impulse Noise Protection (G.998.4)" to Disabled.

As for issue with ADSL WAN (ATM) WAN connection type PPPoA, there is a beta firmware available that could resolve the problem, please download from the link below. This fix will also be included in next official firmware release. Thanks.

DSL-AC68U_3.0.0.4_376_3361-g41e8462_DSL_1017b_1009.trx.7z
https://www.asuswebstorage.com/navigate/s/C7E2BA02B8B944DE8C78B2B4C1E463514

Best regards,
Paul Lee"

I will keep chasing Asus for a fix and resolution on this product.

Anthony
 
Shocked of a Sheffield

Just had email back from Asus second line. They are saying that, because I find it unacceptable that the HH5 works at 64Mbps and that the DSL-68u works at 49Mbps, that I should return it if I am able. I should be advised that speed difference is normal and that speeds depend on multiple factors.

A number of things:
1) the line rate of the HH5 was 68Mbps, not 64Mbps
2) we never proved that the Asus would work in a stable manner at 49Mbps - I said it was unacceptable to have such a reduction in the same circumstances on the line and past experience would suggest that the line would not be stable with the asus on there which lead to even slower speeds once DLM did its thing.
3) this is normal? Seriously? A 28% line speed reduction is normal?
4) no acknowledgement that work was taking place by Asus to resolve known issues is just poor. I go back to "normal". Hence speechless.

Note: I didn't buy the device at Overclockers and I was just following the advice and guidance that may be available to overcome the current problems. I didn't want you guys contacting Asus as a result.
 
Last edited:
Sorry was not trying to single out any particular person just that they are doing what they can to resolve all the issues. They read our Forum as they know the people on here want the best out of there equipment and like to play around with settings.

But really more of the bugs could have been squashed before it was released.
 
You must log in or register to reply here.
Back
Top Bottom