Anyone Using an Asus DSL-AC68U

In TC is this. i think it does same job as in Router

Code:
>adslphxcmd help
Usage: adslphxcmd begin [--up] [--modulation {a|d|l|t|2|p|e|m}] [--bitswap {on|o
ff}] [--sra {on|off}]
       adslphxcmd end
       adslphxcmd connect [--up] [--down]
       adslphxcmd info [--state] [--show] [--stats]
       adslphxcmd delt [--start] [--status] [--show {snr|qln|hlin|bits|actatp}]
       adslphxcmd fwversion
       adslphxcmd driverversion
       adslphxcmd version
       adslphxcmd help

Here are some of my stats. very high FEC
Code:
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
near-end path0 fec:     75070352(75068976)
near-end path0 crc:     3(3)
near-end fec sec:       51320(51323)
near-end err sec:       1(1)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(30)
far-end path0 fec:      621(43223)
far-end path0 crc:      0(266)
far-end fec sec:        43(2350)
far-end err sec:        0(71)
far-end ses sec:        0(0)
far-end los sec:        0(270)
far-end ua  sec:        0(10396)
outDiscards=5700
inDiscards=85
outBytes=367590268
inBytes=1426443379exit
outPkts=2458180
inPkts=4502846
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.0 dB
AttenDown=9.3 dB
SNRMarginUp=6.1 dB
AttenUp=0.1 dB
DataRateDown=61341 kbps
DataRateUp=19993 kbps
WanListMode=0
FECDown=75070123
FECUp=621
CRCDown=3
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=15:51, 9 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.6 dbm
PowerUp=3.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=20956
AttainDown=76956
ShowtimeStart=19
TotalStart=38
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=919
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
tc>
 
@ bitsNbobs ... intresting finding ... will point this to asus

@ ixel ... what do you mean by TCM?

Thanks

Trellis coded modulation.

-----

I've now increased my downstream sync rate to 72Mbps and will test that for another 24 hours on INP 0, delay 8ms, with TCM still off. Prior to that I didn't encounter an abnormal FEC error count at all.
 
In TC is this. i think it does same job as in Router

Code:
>adslphxcmd help
Usage: adslphxcmd begin [--up] [--modulation {a|d|l|t|2|p|e|m}] [--bitswap {on|o
ff}] [--sra {on|off}]
       adslphxcmd end
       adslphxcmd connect [--up] [--down]
       adslphxcmd info [--state] [--show] [--stats]
       adslphxcmd delt [--start] [--status] [--show {snr|qln|hlin|bits|actatp}]
       adslphxcmd fwversion
       adslphxcmd driverversion
       adslphxcmd version
       adslphxcmd help

Tried a while back, doesn't seem to work on this device though, so all operations must go through wan or tcapi.

Also - as a test to back up my TCM results, you might want to try switching off TCM for a time to see if your abnormal FEC error count remains fairly sane.

Code:
wan vdsl2 set tcm off
wan dmt set tcm off
wan adsl close
wan adsl reset

Run the above four commands via TC and keep an eye on your FEC seconds and FEC error count on the near-end path0. Of course, only applicable if you're interleaved which you currently are.
 
Last edited:
10 days and 4 hours, broken my own record...

My stats:
outDiscards=1190
inDiscards=561
outBytes=3443068099
inBytes=2713808692
outPkts=26459474
inPkts=45430329
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.2

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=14.5 dB
SNRMarginUp=12.8 dB
AttenUp=0.1 dB
DataRateDown=39998 kbps
DataRateUp=9994 kbps
WanListMode=1
FECDown=658016041
FECUp=48
CRCDown=149
CRCUp=3
HECDown=0
HECUp=0
ADSLUpTime=4 days, 6:14, 33 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.3 dbm
PowerUp=6.6 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=20193
AttainDown=77940
ShowtimeStart=19
TotalStart=78
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=2313
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
admin@DSL-AC68U:/tmp/home/root#
 
658million FEC - this really can't be counting correcty!

Also, you mentioned in last post 9 days since WAN disconnect. The stats above show ADSL uptime of 4 days just. This could explain why you're not getting interleaving removed as if the device was stable for 9 days I'd have expected DLM to remove interleaving.
 
So far it's looking more likely that TCM is adding to the highly abnormal FEC error count, somehow. I'll be posting another set of statistics in the next couple of hours. Increasing my sync rate from 64Mbps to 72Mbps has encouraged more CRC errors to appear, but nothing alarming whatsoever. The other good news is that, according to another forum, BT Openreach are imminently about to rollout G.INP (from the start of this year). I can only assume that means at some point during Q1 of 2015 we'll begin seeing G.INP being used by DLM or enabled on our VDSL2 connections.
 
658million FEC - this really can't be counting correcty!

Also, you mentioned in last post 9 days since WAN disconnect. The stats above show ADSL uptime of 4 days just. This could explain why you're not getting interleaving removed as if the device was stable for 9 days I'd have expected DLM to remove interleaving.


Dsl log states over 10 days, weird., if it is the case that mine isn't stable then that isn't good news but nobody has pointed this out before...
 
Last edited:
Hmm, well I don't think DLM considers FEC anyway - or at least that's what I'm told and I honestly believe would make sense for it to only consider ES, SES, synchronisations and SNRM variance.

Unfortunately I have bad news, the FEC is now going wild again - disabling TCM might have kept the FEC error count sane for longer, but not indefinitely. I will however compare the CRC errors with and without TCM to see if there's much difference - initially and so far it seems there is, but again might just be a 'placebo' effect.
 
@RedBull2k

The adslphxcmd only affects settings/options already displayed and available in the routers basic web interface/config.
If for example you set something like "adslphxcmd begin --sra off" it would connect with SRA (seemless rate adaptation) set to off/disabled. However if by default SRA is normally enabled then the next resync after that initial sync will just mean the command has to be issued again, as the connection will just resync with its default values. Basically "adslphxcmd" is nothing more than what you can see or do in the web interface already.

@Evil Shubunkin and the following quotes...
658million FEC - this really can't be counting correcty!

Also, you mentioned in last post 9 days since WAN disconnect. The stats above show ADSL uptime of 4 days just. This could explain why you're not getting interleaving removed as if the device was stable for 9 days I'd have expected DLM to remove interleaving.

Yep obviously the FEC figure is wrong, if you look at some ES or CRC figures from people then look at the FEC figures and do the maths for some posted stats it works out that something like 50 years worth of errors (based on an error being corrected every second IE taking the ES value) are being corrected for about every 5-24 hours of connection time (depending on whos posting). As i said earlier there is no way that is right you would be sitting there for ages, probably 30 mins each time you just wanted to load a web page :D
More inconsistencies with this device!

Would have thought something as simple as uptime would match between the gui and text file.

With regards to UPTIME stats, the 9 day figure will be the total time the router has been up (IE powered/actually working or time spent actually doing routing, it will be one or the other) The 4 day odd figure will be the time the DSL side has been up and running or how long the current IP has been leased for. This is not "inconsistent" or wrong, it is exactly what other devices do. Netgear devices count both items but label them the same, even rubbish like a BT home hub counts hub uptime and connection uptime, but remarkably they do name the items in the config different. It is not unusual or a device defect in any fashion. Its possible he has actually had 9 days up time but his IP address renews (gets a new lease) every 5 days or there abouts. Again normal.

Hmm, well I don't think DLM considers FEC anyway - or at least that's what I'm told and I honestly believe would make sense for it to only consider ES, SES, synchronisations and SNRM variance.

Unfortunately I have bad news, the FEC is now going wild again - disabling TCM might have kept the FEC error count sane for longer, but not indefinitely. I will however compare the CRC errors with and without TCM to see if there's much difference - initially and so far it seems there is, but again might just be a 'placebo' effect.

@Ixel
I think i may have spotted another pattern due to you stats and what chriscatt has just posted with his.

With your FEC and how it suddenly goes mental after a certain period.... Firstly How long is the uptime not necessarily of just the connection but the device also typically when you think you have fixed FEC under any circumstance (IE killing spectrum, killing SRA, killing TCM etc) in a combination or combined (doesnt matter)??? Would you say roughly it is 24 hours or getting towards that? For both or either and then the FEC goes wild again?

IF so....... Look in the device for an "IP Lease time setting" (may be named slightly different) if that is set to something like 12 or 24 hours, or even 1 day, try altering it to 48 hours (or 2 days depending on what the config uses) and see what happens then ;)

Killing the spectrum, TCM etc etc may only apply to the currently leased IP address, even if after a set period it leases the same IP address again it has "renewed" it which the "kill" commands may not recognise and thus just stop functioning and allow Spectrum and TCM to get applied/come up again.

Also if there is one (this is rarer) look for a DNS lease time and increase that if its a 24 hour figure.
 
TCM disabled
spectrum killed.
g.inp disabled
g.vector disabled
vdsl profile 17a
bitswap enabled
sra enabled
upbo auto

Not sure why i have high fec, i have noticed my bt profile has increased after 24 hours of uptime it is now at 68 which is what i was getting with my eci modem. Just need to drop the ppp session for new speeds to take effect, as speed test show im at my old profile.
 
With regards to UPTIME stats, the 9 day figure will be the total time the router has been up (IE powered/actually working or time spent actually doing routing, it will be one or the other) The 4 day odd figure will be the time the DSL side has been up and running or how long the current IP has been leased for. This is not "inconsistent" or wrong, it is exactly what other devices do. Netgear devices count both items but label them the same, even rubbish like a BT home hub counts hub uptime and connection uptime, but remarkably they do name the items in the config different. It is not unusual or a device defect in any fashion. Its possible he has actually had 9 days up time but his IP address renews (gets a new lease) every 5 days or there abouts. Again normal.

If you look at the screenshot, it is labelled DSL Uptime, not router uptime which is found on the main system log page. So the DSL Uptime on the DSL log page should match the text file.

The PPPOE session is separate to the DSL side of things, so any session drops and new IP addresses will not automatically cause the DSL connection to drop and thus the DSL uptime should continue counting irrespective of whether there's a connected PPPOE session or not.
 
@Ixel
I will later 2nite at about 3am do as requested to back up your tcm results.

@bitsNbobs
What you say about lease time and 24hours etc, does make sence both my dsl ac 68u and my returned dsl n66u both had a problem when it would reach a 24hour period, sometimes shorter
 
@ixel
I will later 2nite at about 3am do as requested to back up your tcm results.

@bitsnbobs
What you say about lease time and 24hours etc, does make sence both my dsl ac 68u and my returned dsl n66u both had a problem when it would reach a 24hour period, sometimes shorter

Switching off TCM didn't resolve the abnormally high FEC, only did for the lower sync rates.
 
My uptime is 35 days, this I've copied from the main log:
Jan 5 20:43:31 miniupnpd[5204]: recv (state0): Connection reset by peer
Jan 9 11:35:46 miniupnpd[5204]: recv (state0): Connection reset by peer
Jan 10 11:22:28 syslogd started: BusyBox v1.17.4
Jan 10 11:22:33 DSL-AC68U: start httpd
 
Last edited:
If you look at the screenshot, it is labelled DSL Uptime, not router uptime which is found on the main system log page. So the DSL Uptime on the DSL log page should match the text file.

The PPPOE session is separate to the DSL side of things, so any session drops and new IP addresses will not automatically cause the DSL connection to drop and thus the DSL uptime should continue counting irrespective of whether there's a connected PPPOE session or not.

It doesn't just continue though, ive seen it in Netgear, TPlink and with the BT home hub. It is not unusual. It would also start recounting if he changed any DSL related setting during the uptime period. PPPOE uptime on this device (if there is a way to display it) is likely to state the time you have been connected to the device. While i agree that what they have called these stats is not clear it is not unusual or a quirk, fault or whatever you want to call it of this device.
Even the UPTIME counters on a HG612 supplied by Openreach are misguiding to say the least, example...
http://forum.kitz.co.uk/index.php?topic=10289.msg205454#msg205454
and bottom of that post.
TCM disabled
spectrum killed.
g.inp disabled
g.vector disabled
vdsl profile 17a
bitswap enabled
sra enabled
upbo auto

Not sure why i have high fec, i have noticed my bt profile has increased after 24 hours of uptime it is now at 68 which is what i was getting with my eci modem. Just need to drop the ppp session for new speeds to take effect, as speed test show im at my old profile.

Disable SRA and ensure your spectrum is killed after disabling any other setting.
My uptime is 35 days, this I've copied from the main log:
Jan 5 20:43:31 miniupnpd[5204]: recv (state0): Connection reset by peer
Jan 9 11:35:46 miniupnpd[5204]: recv (state0): Connection reset by peer
Jan 10 11:22:28 syslogd started: BusyBox v1.17.4
Jan 10 11:22:33 DSL-AC68U: start httpd

Just ignore inbuilt UPTIME counters they will only confuse the situation. As has already started ;)
 
Re-enabling TCM seemed to make the FEC go wild quicker than it did when it was disabled at 72Mbps downstream sync rate.

Also, as a note, BT Openreach are supposed to be rolling out G.INP to VDSL2 connections (FTTC) this month - it's unknown as to whether this will be applied by DLM or whether it will just be enabled on all connections by default anyway (would seem more sensible since G.INP is a dynamic form of interleaving and so is non-intrusive compared to the conventional interleaving and INP). If it's mandatory then disabling G.INP on the ASUS DSL-AC68U may result in no sync when G.INP is enabled on your connection.
 
So I have to look at the adsl uptime to see that my modem is as unstable at holding a connection as any others? Can I ask again if there would be anything gained by updating to the latest firmware?
 
Back
Top Bottom