Anyone Using an Asus DSL-AC68U

Do you know what cabinet you are on, ECI or Huawei?

I'm not sure! I'll try and find out and report back :)

bitsNbobs said:
It will not make any difference at all, your modem end does not control if G.INP is applied in any way shape or form, in fact having that option in the devices interface for UK users once again confuses issues. G.INP is set at the cabinet similar to how DLM operates. You can not choose if you want it on or not, it will just be applied if the system thinks you need it. Likewise if you are on a cabinet that does not currently support it (IE ECI cabinets) alter that setting to on or off will make no difference. That setting much like the SRA one for the UK market basically has ZERO impact on a FTTC connection. SRA should not even affect a UK based ADSL connection but can depending on the algorithm implemented by the device.

Ah, okay. I'm not familiar with this at all, so I'd take your word for it, but this article I read to try and brush up before posting seems to suggest that a modem has to support G.INP to take advantage of it...

It’s not exactly obvious when G.INP has been enabled ... What makes the situation worse is the fact that some modems may not currently support G.INP.

It the article isn't just making things up, it would make sense for a modem to have a G.INP mode. Also, it seems kind of daft for the developers to include an on/off setting that makes no difference to the user. They can't just have made a button that only changes the text next to the button...?
 
Last edited:
It's more a 'capability' setting. If G.INP is disabled on the modem but the DSLAM has it enabled, there's a possibility you'll be put on an interleaved profile instead - therefore making G.INP optional should for some reason the user not want to use it if the DSLAM supports it.
 
It's more a 'capability' setting. If G.INP is disabled on the modem but the DSLAM has it enabled, there's a possibility you'll be put on an interleaved profile instead - therefore making G.INP optional should for some reason the user not want to use it if the DSLAM supports it.

Ah, I think I see! So if it turns out my line is coming from one of the cabinets that currently supports G.INP, then I've got nothing to lose by setting it to "enabled", and potentially something to gain (ie a line that has less chance of becoming interleaved)?
 
Last edited:
It's more a 'capability' setting. If G.INP is disabled on the modem but the DSLAM has it enabled, there's a possibility you'll be put on an interleaved profile instead - therefore making G.INP optional should for some reason the user not want to use it if the DSLAM supports it.

Thats not quite right, if the modem is INCAPABLE of G.INP you get put on an interleave setting instead. The Asus according to people much earlier in the thread even before firmware version that had the G.INP setting in the interface as a setting was capable of G.INP and applying it to lines.

This is currently happening with some BT ECI modems and the only way to solve it is via a Line profile resetting by openreach to force downloading of new firmware that supports G.INP to that device.

Whatever he sets that G.INP setting in the Asus it will make no difference, if G.INP is enabled, cabinet sends the G.998.4 bearer to the end user device, if the device is capable it then switches to G998.4 rather than G.993.2. The same will happen when vectoring comes along adevice should auto enable that and switch to G.993.5.

There is no way to enable or disable G.INP or pick and choose (well actually there may via TC Console and re-forcing G.993.2) but not via that interface setting.

People now asking questions are better off just leaving any device set to its defaults rather than mess around. In fact id say that goes for any setting on this mentally fragile ;) Asus device. I highly doubt anyone whos stats were showing G.993.2 before being G.INP'd can switch back to G993.2 (instead of the blank entry OPMODE the device shows when G.INP'd) and get it to show G.993.2 again. Thats not how it works.


Oops, My mistake then. I just presumed it had gone interleaved after he said he gained an 8ms in ping results.

He was already interleaved see post number #1697, (currently page 57) infact see all posts with regards to his issues from page 56 (ish) onward. Various information he has provided does not compute for some reason. Do not think he was ever fastpath, which is interesting as i doubt a 8ms ping without it and i doubt the connection would yoyo back and forth so frequently and quickly if it could not decide, typically regular back and forth changes like that take a month plus at a time. It certainly would not switch interleaving on AND off every few days, only one or the other.

The thread has unfortunately became full of misunderstanding for about the last 10-20 pages.
 
Last edited:
He was already interleaved see post number #1697, (currently page 57) infact see all posts with regards to his issues from page 56 (ish) onward. Various information he has provided does not compute for some reason. Do not think he was ever fastpath, which is interesting as i doubt a 8ms ping without it and i doubt the connection would yoyo back and forth so frequently and quickly if it could not decide, typically regular back and forth changes like that take a month plus at a time. It certainly would not switch interleaving on AND off every few days, only one or the other.

The thread has unfortunately became full of misunderstanding for about the last 10-20 pages.

I must have missed that information. Strange issue then.
 
The higher the rate gets the smaller the increase or decrease will happen. As to how much higher you will go is totally down to your line. If that rate is near to the maximum your line can do you will not see many more increases, if its nowhere near what the line can manage with everything running well it will continue to add between 3-8Mb at a time.


pre asus i was getting 68mb down and 18mb up in throughput, the first banding i remember being on is around 48mb , so your saying ill be put on banding rate 52 then 56 etc until i get to the speeds i was getting before:confused:?
 
pre asus i was getting 68mb down and 18mb up in throughput, the first banding i remember being on is around 48mb , so your saying ill be put on banding rate 52 then 56 etc until i get to the speeds i was getting before:confused:?

NO it could jump anything from 3-8Mb in a single go, you could go from 48Mb to 56Mb in one go or it may be in several stages, once you get around the mid 50s Mbs it will take significantly longer to boost you back to the full 68Mb, getting the last 10Mb or so back is typically what takes the longest.
 
@bitsNbobs: I don't follow. What bit of my post wasn't right? I thought that was pretty much what I said.

The bit about if G.INP is disabled on the modem is wrong. IF your device supports G.INP (like people are saying the Asus does) and the DSLAM supports it and sends the bearer to the end user equipment it will be enabled, its a modulation (or rather a variation of sorts). It will not matter if you turn it on or off. The setting in the Asus interface is basically pointless with regards to how BTs system here in the UK works.

Think of it like if you have a modem that supports ADSL and VDSL and you are on a VDSL service, the device automatically knows to sync as VDSL and not ADSL thats due to the modulation and G.XXX standard sent to the device. If you have a enable or disable setting it will not make a blind bit of difference, if the DLM system thinks you need G.INP it will just be applied. Some devices do not even have a on/off/enable/disable setting. If you have a device where you can force it to sync as ADSL or VDSL, then it just would not connect at all if you are VDSL, the same basically goes for the new G.INP

If your device does not support G.998.4 (G.INP) but the DSLAM does the DSLAM and DLM system first attempts IF NEEDED to make your device sync using G.INP (AKA G.998.4) if it can not because your device does not support that, then the DSLAM and the DLM system decides ah you got noise on your line (or whatever the issue is) fastpath will not be reliable and i can not apply G.INP so i will interleave the device and reconnect using traditional G.993.2 instead with an appropriate level of interleaving.

The problem with ECI devices and a few others is some support it on the downstream or upstream only leading to issues of various descriptions all the way from device not connecting at all to loss of speeds, and higher latency.

The short version is (in typical fashion) BT with their useless DLM system has screwed up...... AGAIN. IMO anyone supplied a ECI modem should at BTs cost have it replaced as it is technically speaking not compatible with the product that is being supplied. Chances of that happening though as they are so cheap is basically ZERO and people that get cut from 70+ Mb to 50Mb will just be told the connection is working within guidelines.

The best course of action at the moment appears to be if you are on a Huawei cabinet is to buy a Broadcom chipset device if you do not have a Huawei BT modem which supports G.INP and will be a nice match for the DSLAM in the cabinet.
 
Last edited:
Just an update to say that not everything may be over yet. After several days of uptime on a lower INP and delay (3/0 8ms/1ms) my FEC seconds has started counting up every second constantly, causing the FEC errors statistic to go flying upwards.

This doesn't mean necessarily that the device is still unstable, though it's obviously not right given no other modem I have used does similar. I'll know how stable it is when DLM restores fastpath and I run that for quite a number of days/weeks.
 
Just an update to say that not everything may be over yet. After several days of uptime on a lower INP and delay (3/0 8ms/1ms) my FEC seconds has started counting up every second constantly, causing the FEC errors statistic to go flying upwards.

This doesn't mean necessarily that the device is still unstable, though it's obviously not right given no other modem I have used does similar. I'll know how stable it is when DLM restores fastpath and I run that for quite a number of days/weeks.

LOL funny how i said several pages back now burried in the quagmire of new posts, misunderstanding posts and posts that have jumped right in without reading any of the thread that ill believe its fixed when i see someone with reliable stats on fastpath ;)

Does not sound good Ixel, though hope it stays stable for you :)
 
LOL funny how i said several pages back now burried in the quagmire of new posts, misunderstanding posts and posts that have jumped right in without reading any of the thread that ill believe its fixed when i see someone with reliable stats on fastpath ;)

Does not sound good Ixel, though hope it stays stable for you :)

Don't mean to cause conflict however nobody is here to prove anything to you or to make you buy it, there are those with no issues and those with plenty of issues and some who had minor issues which have been fixed.

Also anybody who owns this router and buys items from Overclockers is more than entitled to post here, regardless of whether or not you personally find it useful or not. Nobody else in this thread has commented or not on whether or not anything people post is useful or not, you are on your own in telling people there posts are not up to what you expect or some hidden standard in your head. Leave the moderators to do there job and say what can or cannot be posted otherwise you will just stress yourself out for no reason.

I think the main point many have hit upon in the thread though is why do so many alternatives have no issues out of the box vs this router, why has it taken so long to fix.

Regardless of the fixing of issues for certain people and the fact it works flawlessly for myself, I think I would be hesitant in buying another DSL based product from ASUS in the future or recommending one to other people.

That being said, there are very little performance options on the market for all in one VDSL Modem and router combined. Separate modem and router in future might be the best option if I ever have to move to somewhere farther from the cabinet etc.
 
Don't mean to cause conflict however nobody is here to prove anything to you or to make you buy it, there are those with no issues and those with plenty of issues and some who had minor issues which have been fixed.
No conflict felt and i do not feel anyone has to prove anything to me, also agree with all that apart from maybe the "some who had minor issues which have been fixed." Thats unknown until the device proves it can recover properly from DLM intervention and record stats properly which so far all the sensible evidence says it can not.
Also anybody who owns this router and buys items from Overclockers is more than entitled to post here, regardless of whether or not you personally find it useful or not.
Agree entirely, useful or not everyone has a right to post, its just a pity some do so without reading the entire thread first, yes its long but self education is always a good thing.
Nobody else in this thread has commented or not on whether or not anything people post is useful or not, you are on your own in telling people there posts are not up to what you expect or some hidden standard in your head.
Sorry you feel that way or i have come across in that manner, i just feel its a shame that good information from a number of posters has now become buried in pages of discussion which was done/covered much earlier in the thread.
Leave the moderators to do there job and say what can or cannot be posted otherwise you will just stress yourself out for no reason.
Its no stress at all just an observation, and a view point about the thread which we both clearly have and have the right to :)
I think the main point many have hit upon in the thread though is why do so many alternatives have no issues out of the box vs this router, why has it taken so long to fix.
Its pretty much a combination of things but the real causes are poor software (IE the firmware) and the DLM system in the UK.
Regardless of the fixing of issues for certain people and the fact it works flawlessly for myself, I think I would be hesitant in buying another DSL based product from ASUS in the future or recommending one to other people.
Totally understand that view that is basically the reason i have not rushed to buy another after returning a faulty one.
That being said, there are very little performance options on the market for all in one VDSL Modem and router combined.
DUnno if i agree with that, there are quite a few options now, obviously no where near the amount of ADSL devices but it will take years to reach that level.
Separate modem and router in future might be the best option if I ever have to move to somewhere farther from the cabinet etc.
Just make sure its a broadcom chipset due to the G.INP issues with BT gear and some manufacturers end user equipment. ;)

PS glad it is still working fine for yourself thus far though :) Hope it continues :)
 
LOL funny how i said several pages back now burried in the quagmire of new posts, misunderstanding posts and posts that have jumped right in without reading any of the thread that ill believe its fixed when i see someone with reliable stats on fastpath ;)

Does not sound good Ixel, though hope it stays stable for you :)

That could be due to a bad raining day as example (raised some burst errors after many days)
But will show up if carry on raising errors
 
I've just noticed, via TC, that my SNRM on band 1 (DS presumably, of 0, 1 and 2) is fluctuating a bit than I usually notice.

For a period of every 10 seconds, averages seem to be going between a min/max of 6 dB to 7 dB. Usually they're rather consistent. This might be the reason why my FEC errors have gone upwards every second I expect.
 
Over 7 days now on fastpath (as my line was before I swapped over) and no sign of any issues - CRC count is lower than the HG612 would be, assuming the ASUS is counting correctly of course.

Saying that now I'll probably be interleaved overnight :)
 
Edit: Can't find the links again but it was on plusnet and Kitz. I noticed two people reporting speed drops of approx 10% since installing the latest firmware. They were advised to reload previous firmware which saw the return of their speed. A new bug in the firmware perhaps?
 
Last edited:
Back
Top Bottom