Anyone Using an Asus DSL-AC68U

I can bring some good news to this thread. It would seem that DLM doesn't consider FEC at all. I had billions upon billions of them rapidly counting upwards on the downstream, yet leaving the modem alone for 9 days of uptime it appears to have relented and increased my speed band from 49Mbps to 54Mbps and reduced the INP from 7 to 6. I've now applied the new MTU and will see if it makes any difference over time.

Over four hours of uptime and no sign of a massive FEC increase yet. CRC errors on the upstream are also lower than usual.
 
Last edited:
andy66 said:
For reference, using OR HG612 modem (and a DSL-N66U in Ethernet WAN mode [with settings MTU=1492, MSS=0])
http://www.speedguide.net/analyzer.php tells me:
MTU = 1492
MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput.
MSS = 1452
MSS is optimized for PPPoE DSL broadband. If not, consider raising your MTU value.
Click to expand...

Sorry for not being too clued up on this but is that showing the MTU of the modem or the router?

I'm just looking into buying one of the Dsl-ac68u's just now. Even if the MTU issue doesn't fix the problem. I would happily assist Asus in trying to get it to work correctly with submitting logs and info.
 
michty_me said:
Sorry for not being too clued up on this but is that showing the MTU of the modem or the router?

I'm just looking into buying one of the Dsl-ac68u's just now. Even if the MTU issue doesn't fix the problem. I would happily assist Asus in trying to get it to work correctly with submitting logs and info.
Click to expand...

That detects the MTU of the router, or at least it did when I tried it here.

Progress update:
Code: 
ADSL uptime : 7:11, 50 secs
near-end path0 fec:     268523(268523)
near-end path0 crc:     1(1)
near-end fec sec:       764(764)
near-end err sec:       1(1)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      178(837792)
far-end path0 crc:      24(3439)
far-end fec sec:        29(19067)
far-end err sec:        14(2704)
far-end ses sec:        0(0)
far-end los sec:        0(1098)
far-end ua  sec:        0(44934)

54M/20M, INP 6/0, Delay 16/1

MTU - 1024 (very conservative setting for now)

4215660752.png
 
Last edited:
Ixel said:
That detects the MTU of the router, or at least it did when I tried it here.

Progress update:
Code: 
ADSL uptime : 7:11, 50 secs
near-end path0 fec:     268523(268523)
near-end path0 crc:     1(1)
near-end fec sec:       764(764)
near-end err sec:       1(1)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      178(837792)
far-end path0 crc:      24(3439)
far-end fec sec:        29(19067)
far-end err sec:        14(2704)
far-end ses sec:        0(0)
far-end los sec:        0(1098)
far-end ua  sec:        0(44934)

54M/20M, INP 6/0, Delay 16/1

MTU - 1024 (very conservative setting for now)

4215660752.png
Click to expand...

Thanks. Just wasn't sure as I don't know what stats/info are available through the HG612.
 
Another update. Sadly MTU didn't help with the FEC anomaly, only time will tell if and when I eventually get back to fastpath whether it helps reduce the CRC errors.
 
Well after a lose of speed and fastpath while setting it up (kinda restarted it abit too much :P and was doing it in the morning)

kumdxAH.png


No crc errors for 8 hours i wil see if it suddenly dies at some point... :P
 
Not sure what you mean by the crc's, mine never had a high count and still was forced onto interleaved....
 
Last edited:
Ixel said:
I can bring some good news to this thread. It would seem that DLM doesn't consider FEC at all. I had billions upon billions of them rapidly counting upwards on the downstream, yet leaving the modem alone for 9 days of uptime it appears to have relented and increased my speed band from 49Mbps to 54Mbps and reduced the INP from 7 to 6. I've now applied the new MTU and will see if it makes any difference over time.

Over four hours of uptime and no sign of a massive FEC increase yet. CRC errors on the upstream are also lower than usual.
Click to expand...

Ixel said:
Another update. Sadly MTU didn't help with the FEC anomaly, only time will tell if and when I eventually get back to fastpath whether it helps reduce the CRC errors.
Click to expand...

Did it get to around the 6 hour mark before the errors returned? If so that would indicate a bit loading issue on the VDSL routine. Another way you can check that is in TC Console disable a handful of tones in the middle of the frequency spectrum if after 6(ish) hours it stops obeying the killed tones and starts to use them then that is definitely a bit loading issue. Again it would be something easier to fix if they released the firmware complete with xDSL drivers included. Personally i feel the issue is so minor as in many cases its long term use (over 24 hours) before things really start to go to pot. Asus ideally need to recompile and check each function/module to the code from scratch, or release a simplified/tiny firmware with a load of the crud removed.

Its definitely something to do with either tone allocation or memory fragmentation (this i still suspect due to all the crud in the firmware and separate code and modules). Both they really should had fixed by now especially if they had any coders with even half a clue. Maybe they should stick to motherboards, which software wise are basic ;)
 
My bubble was popped quite quickly following a change of the MTU value to 1452 - 7 minutes in and 643 CRC errors already. The other observation was the UI was almost unusable based on the speed of response I was getting.

Although it was a short test, I submitted via the feedback form. Following the submission, the unit had a full set of indicator lights but was not communicating with the outside world at all. This was not just the browser that had submitted - it was everything connected to the network.

Back to the HH5 I went.
 
sumowesley said:
My bubble was popped quite quickly following a change of the MTU value to 1452 - 7 minutes in and 643 CRC errors already. The other observation was the UI was almost unusable based on the speed of response I was getting.

Although it was a short test, I submitted via the feedback form. Following the submission, the unit had a full set of indicator lights but was not communicating with the outside world at all. This was not just the browser that had submitted - it was everything connected to the network.

Back to the HH5 I went.
Click to expand...

Altering the MTU OF THE ROUTER should make no difference to the speed of the routers web UI.
MTU on the router side adjusts incoming packet size. Altering it for your NETWORK ADAPTER could slow things but not to anything even close to "unusable" No idea what you have done there. Submitting reports with any settings drastically altered is also probably not a good idea and will just confuse the issues at the ASUS end of things, unless the reports the device sends include every setting the device is using which i frankly doubt.
 
I certainly wasn't linking MTU to the UI - that slowness seems to be on this release as it was similarly slow on my last sojourn. However, it makes running any form of test very difficult.

There is a set of tick boxes on the submission page which includes one for config - I would assume MTU is included but I can't confirm. I'm sure Asus will have the expertise to sift through the submissions and select ones that are suitable.
 
sumowesley said:
I certainly wasn't linking MTU to the UI - that slowness seems to be on this release as it was similarly slow on my last sojourn. However, it makes running any form of test very difficult.

There is a set of tick boxes on the submission page which includes one for config - I would assume MTU is included but I can't confirm. I'm sure Asus will have the expertise to sift through the submissions and select ones that are suitable.
Click to expand...

Ah right i thought you meant altering the MTU slowed things apologies.
I would guess the config option/info just includes basic things like connection settings (IE What the VCI and VPI is, whether PPPoE or PPPoA in use etc) Though i could indeed be wrong it may report more.

Ive been refunded on my faulty unit, im now torn as to go for one of these and still try to solve issues, a cheap but seems to be reliable TP-Link W9980 or a more expensive Billion 8200 with ac wifi.
 
michty_me said:
I thought the 8200 was N only and not AC? I know the 8800 is ac.
Click to expand...
Oppps... No idea why i said the 8200 that is the old big black brick model DOH!!

Yep i meant the 8800 models. As quickly covered by Evil Shubunkin...
The 8800NL being the non AC model with only one gigabit ethernet port and the 8800AXL being the AC Wifi and full set of gigabit ports model.

The 8800AXL being the exact model i am considering, though i think for almost another £100 more than the 8800NL model its a bit cheeky especially as im unlikely to use the wifi AC (only time i use wifi for anything is if using my mobile phone at home) and its only really the Gigabit ports i would want (yeah i know could get a switch but that defeats the single box purpose).

Still mighty tempted by the TP-Link TD-W9980 (to give its full name) though, for around £70 its a bargain, has all the features i would want, seems a reliable device, only downside is the interface does not give as many stats as others. Decisions Decisions... Spent £140 on a Billion with decent stat reporting, £70 on a TP-Link W9980 reliable but not as stat eccentric or still go for an Asus DSL-AC68U and try to solve the issues with firmware jiggery pokery ;). I think its going to come down to something as tragic as what mood im in when i click a 'buy' button, if i feel like spoiling myself or saving money, if i feel like tinkering with the Asus or just saying screw it and buying the Billion for a quiet but stat filled life LOL
 
Last edited:
bitsNbobs said:
Still mighty tempted by the TP-Link TD-W9980 (to give its full name) though, for around £70 its a bargain, has all the features i would want, seems a reliable device, only downside is the interface does not give as many stats as others. Decisions Decisions... Spent £140 on a Billion with decent stat reporting, £70 on a TP-Link W9980 reliable but not as stat eccentric or still go for an Asus DSL-AC68U and try to solve the issues with firmware jiggery pokery ;). I think its going to come down to something as tragic as what mood im in when i click a 'buy' button, if i feel like spoiling myself or saving money, if i feel like tinkering with the Asus or just saying screw it and buying the Billion for a quiet but stat filled life LOL
Click to expand...

You've missed the HH5 from the possibilities :D

However, my money would be on the Billion or Asus. I don't know enough about TP-Link to know whether they would be any good or not and a quick look on the site for that model shows no updates in firmware yet showing additional line stats. That said I believe it uses a Lantiq based modem so if you're connecting to an ECI cabinet then that might be the better option.

I've the 8800NL as I thought I would try that before getting an unlocked HG612 and it did what I expected it to. The only thing I noticed is that ping times were 1-2ms higher consistently with the 8800NL than my separate ECI modem, but that may be down to Broadcom modem connecting to an ECI cabinet. Not a huge issue, apart for online gamers.
 
You must log in or register to reply here.
Back
Top Bottom