Anyone Using an Asus DSL-AC68U

i have it with MTU 1442 (PPPOA vc mux - adsl) so far 5 hrs 0 errors ... before had it with mtu 1462 (that where i did not get fragment packages with my network)

usually by that time are very few(5-23 by the same amount of time 5 hrs & most 300 with in a day) ... hmmm it is raining and normal has always very few with rain ... it does have less according & to the new user above me

too early to tell so finders crossed

EDIT

i have the correct order & unplugging the cable going to the phone socket ... but just did not turn off my pc or other devices
 
Last edited:
@spoonbard Yes if you could monitor it with the 1452 setting for 24-48 hours and report error figures it would be appreciated, if you could then also test with whatever the figure was before the change for another 24-48 hours that will help with comparing things.

@babis unless i remember wrongly (more than possible lol) you are in Greece, i have no idea what the default MTU is for most ISPs out there, in the UK most (NOT all) can get away with something between 1460 and 1500 FOR ADSL ONLY. Many can have a full 1500 set on ADSL. Overseas this may be entirely different. Either way in your experimenting keep it above 1400, anything below that will normally hinder rather than help. Make small changes no more than a difference of 10 at a time.
^^^^ All that figure wise is for any ADSL readers.

Any change you make it is best to restart the computer, this SHOULD ensure windows TCP does not try to send anything over the MTU size you set in the router.

Doing a ping test like say......
Code:
ping www.google.com -f -l XXXX
where XXXX is the MTU figure you want to test if you are on later versions of windows is pointless in many cases as the TCP in that auto-negotiates so any figure that says it can manage is normally a lie, typically it wll say it can manage everything up to 1500, which on FTTC at least i can say for a fact is a fib as PPPoE does not support MTUs that high. Typically that commonly known test is only 100% accurate in Windows XP/2000 and earlier.

ANYONE on Windows XP can or should be able to use that above trick to find the MTU, though if you are FTTC and it says you can ping with a 1500 setting it is lying.

MTU for anyone reading is basically maximum transmission unit (MTU) If your MTU is too large in size it can lead to retransmissions if the packet encounters a router that can't handle that large a packet. Too small an MTU size means relatively more header overhead and more acknowledgements that have to be sent and handled.

A MTU too large will possible mean errors, typically it affects CRC for many from my experience of deliberately setting it way too high, but i suspect on the Asus due to how inaccurate the errors are reported this may be affecting the FEC count also or at least be contributing to its high figures.

On windows XP and earlier you could set MTU and other connection related settings manually in the OS but on windows vista, 7 and 8 (which i assume most are using now) they have a new TCP (Transmission Control Protocol) which adjusts on the fly. Sometimes this does a poor job at setting a correct RWIN figure (TCP receive window) which can lead to errors. Most devices will handle this fine, but i suspect based on some of the things ive seen in this thread the Asus maybe does not. Thus setting it lower should help (just do not go stupidly low, keep it above 1400).

The 1452 MTU setting for FTTC is a suggestion from the BT homehub 3/Openreach modem combo supplied days which while not very feature rich was in general reliable for FTTC. Its what im currently using and it will not allow me to set anything over 1452 even though ping testing will allow packets at 1500. (again windows TCP auto negotiates so technically its fibs)

Typically you want MTU to be as large as you can get it without retransmissions the only real way to find that out is constant small tweaks and testing. 1452 on FTTC should be probably the best for most people. If you are really attetive you will notice certain sites will load every so slightly faster or slower with MTU adjustments, normally you will see this better on a site that typically loads slow by default (IE it will get even slower or faster depending on MTU).


Anyways its something simple for everyone to have a try and report findings and easy enough to put back should it make no difference. Hopefully it does help, though again im not promising or even that confident it was just more of a hmmmmm thought and worth a go feeling.
 
Last edited:
Thanks for reply and the detailed explanation, that will make clear why & i do have w7 & w8 here

Yes i am in Greece right now

The 1442 for adsl i have set it according to slightly lower ping (ping www.dslreports.com -f -l xxxx) than previous setting (i did check via that method few other lower values) again i m talking with adsl for not any confusion

users with FTTC should do what you have suggested ... i am just reporting and not to confuse

Strange here, firmware 2187 i have PPPoA and the max from asus is 1492 where other modems having 1500 for PPPOA, i will ask asus about it

However for me 13 hrs and still 0 crc ... where other times i had few ( i am not saying i had issues just 0 is surprising) by changing MTU

Well if the OR modem has mtu 1452 as default perhaps that means a lot
( i remember now at draytek forum someone with FTTC mentioned having the draytek default value 1442 was better ... i know by now & thanks it is 1452 but that was the default with that modem so he just left it there & claimed was better)
 
Last edited:
If the issues ever get sorted out on this unit I would buy one in a heartbeat. Kudos to you all sticking with it and trying to get it to work. I hope there are a flurry of single box options in 2015!!
 
I had very low crc's but still had to put up with the modem running interleaved. Swopped it out for the OR modem and within days I think that I am back up to where I should be so I am not convinced it is the CRC's that caused the DLM to reset all the time. Also when you interupt the connection dlm will think it is a line fault thus I suggest a disconnect should be for at least 15 mins or more.http://www.skyuser.co.uk/forum/sky-dlm/23760-what-dlm-everything-you-need-know.html
 
I had very low crc's but still had to put up with the modem running interleaved. Swopped it out for the OR modem and within days I think that I am back up to where I should be so I am not convinced it is the CRC's that caused the DLM to reset all the time. Also when you interupt the connection dlm will think it is a line fault thus I suggest a disconnect should be for at least 15 mins or more.http://www.skyuser.co.uk/forum/sky-dlm/23760-what-dlm-everything-you-need-know.html

A single unplug and re-plugging in of the modem should not cause DLM to auto kick in. Its a certain amount of disconnects in a 24-48 hour period which will cause it (i think ixel has touched on this before). Ive regularly played about with my modem on the master socket and an extension socket from the filtered faceplate terminals and have never had an issue. Have sometimes done that 3 or 4 times in a single day.

The moment you start to regularly interrupt things (every few minutes) or have already been suffering disconnects or DLM already is normally when problems and DLM starts to rear its head. The rest of the time you should be able to unplug or even power off the modem/router with no ill effects.
 
I just played it caucious with this device, as it is unpredictabe. Yes you can get away with one or two but that wasn't stated. Babis3g, if you are in greece you don''t have dlm I believe, one would expect it to be stable as it appears that it mostly uk users have the disconnects and forced interleaving...
 
Last edited:
@spoonbard Yes if you could monitor it with the 1452 setting for 24-48 hours and report error figures it would be appreciated, if you could then also test with whatever the figure was before the change for another 24-48 hours that will help with comparing things.

Checked it this morning - the stats had all reset, and I'd been put on Interleaved. No idea why! Is there any way to access a history of errors to see if there was a spike, or a number of disconnects in a row?

Could it have been all the faffing about installing the new modem/router and changing the settings that did it?

Anyway, since that happened, download is down from 39 to 30, upload is down from 9.5 to 8, and ping has doubled from about 18ms to 35ms, but only 30 CRC errors in 7 hours.

I'll keep it running to see if I get put back on FastPath.
 
The system log will tell when a reset happens, don't hold your breath about this modem going back to fastpath as I found with mine once on interleave that's the way it stayed....
 
regarding the method with mtu to 1452

to see if the windows pc has the modem's mtu try this via cmd

netsh interface ipv4 show subinterfaces

and yes it does need to restart all network devices ... the first time took the mtu from the modem automatic ... now after few few more changes with the mtu in the modem did not take the settings from the modem (according to the netsh cmd command)... the pc needs restart indeed
 
Last edited:
How are you intending on obtaining the crc stats as there will be no dsl log unless the modem is used. As I stated, now mine is just a gateway/router/ap, it has been stable to the point of fastpath being reinstated, I think...
 
Last edited:
How are you intending on obtaining the crc stats as there will be no dsl log unless the modem is used. As I stated, now mine is just a gateway/router/ap, it has been stable to the point of fastpath being reinstated, I think...

The CRC etc from the 612 I meant, the 68 is just for router duties.
 
Ok, I have seen reports of high crc's meaning nothing though. I think the issues with the modem are more to do with how they are being interperated. As I have stated, again, mine never had high crc's but still the modem was being forced down to interleaved all the time. I also know we have done this all before and no-one has been able to really find out why this asus hardware cannot out perform even cheap, nasty, isp supplied modems.
 
I've always been on fast path and that never changed with the Asus, in fact I've not been any slower, but yet I've not improved. The 612 is purely to see how it differs and the e/s that the Asus can't report. I'm 50/50 in swapping it for a Billion 8800axl puelry due to the fact it's £30 cheaper and if I wanted to go back to the Asus it's dropped £10 already.
 
Good luck, so many have tried to work out why the asus is so inconsistant. I thought mine was ok as I only have a 40mbps connection and had low crc's. However once I found that mine had been running interleaved all the time and was never restored to fastpath I gave up. With the advice being given by asus actually making the connection even slower I felt insulted..,
 
Last edited:
I still believe that somehow it's relating the bitswapping algorithm for VDSL2 connections. Why? Because on my connection it starts out fine, then progressively gets worse with more uptime. After about a day the effects start to become noticeable on SES (if I don't have heavy error correction that is) and UA seconds. I don't know why FEC goes crazy over time, or sometimes instantly, either - that also might be related.
 
My money is on you Ixel, however I hope everyone can work together to find out what is causing, what could be a fantastic piece of kit, it to operate in such a unstable and flawed way. What is obvious, from my emails with Asus, is that they think it is down to individual line issues and not their product.
 
Yeah, it's frustrating that they don't accept their product has issues for VDSL2 connections (not all, but a good majority). If it wasn't for the fact my Fritz!Box 7490 crashes at random times then I'd be using that now, when it doesn't it works perfectly - the downstream FEC doesn't go flying upwards either. The HG612 behaves, so does the ECI /r. This is the only device which suffers with issues if I don't have a heavy amount of error correction on the connection.
 
What is obvious, from my emails with Asus, is that they think it is down to individual line issues and not their product.

Absolutely. The last communication I had from Paul Lee was that he said my issues with my modem not being able to stay up for more than an hour even after I had been DLM'd down from 70 Mb to 40Mb was due to a "noisy line".

He conveniently ignored the fact that the HH5 can stay connected for 14+days without a single reset at 70MB. Yet when I have a SNR of 16+ because DLM has kicked in and nearly halved my sync rate and the Asus still cant handle it... it must be my line right?
 
Back
Top Bottom