Anyone Using an Asus DSL-AC68U

simoncraddock said:
I've been looking at info about FEC errors this afternoon trying to establish if BT's DSLAMS look at FEC errors or not when determining whether a line should remain on Interleaving or not and came across a document that states...

Which ones should I actually be concerned about?

The key parameters are the ones concerned with physical layer errors –

Errored Seconds
Code Violations
FECs
Click to expand...

Sounds like Zen's FTTC training document. Yes, I'm pretty sure DLM does consider FEC (either FEC seconds, or the total FEC count, not sure which though).

Ok, agc_vref is 0 at the moment, it has decreased the possible speed as expected, but so far the FEC count (at current rate) is less than what I'd get on the HG612 - which if I recall is more than 3 million per day on my connection.

Code: 
>tcapi get Info_Adsl lineState;tcapi show Info_Adsl;wan vdsl2 show mgcnt
up
outDiscards=0
inDiscards=1160
outBytes=232365622
near-end path0 fec:     7713(907584)

near-end path0 crc:     19(120)
near-end fec sec:       83(706)
near-end err sec:       9(28)
near-end ses sec:       0(9)
near-end los sec:       0(0)
near-end ua  sec:       0(146)
far-end path0 fec:      2022(142452)
far-end path0 crc:      0(1120)
far-end fec sec:        24(4052)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(264)
far-end ua  sec:        0(13278)
outPkts=943807
inPkts=1096092
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.2 dB
AttenDown=10.4 dB
SNRMarginUp=6.9 dB
AttenUp=0.1 dB
DataRateDown=51086 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=7713
FECUp=2022
CRCDown=19
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 2:02, 6 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.6 dbm
PowerUp=4.7 dbm
AttainUp=26135
AttainDown=71788
ShowtimeStart=19
TotalStart=93
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=461
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

As I understand it, vref means voltage reference. I know for sure I was getting both FEC and CRC in no time (within seconds of sync) when I tried a stupidly high number such as 880. If the connection FEC remains consistently lower after 12-16 hours of uptime then I will bump up the vref by 20 each time. Interestingly the parameter has four values, although to my knowledge only the first is used by the modem settings. I don't know what the final three do (if anything).

At the moment it looks promising and has held up longer than last time when I thought FEC was not rising every second of uptime. If this is what it is, then perhaps the AGC's vref is simply too high (amplifying too much, or too sensitive), or perhaps this is just the only way at the moment of bringing errors down to a realistic number.
 
Last edited:
Reading through the thread it seems most of the problems seem VDSL related, but I've only seen the odd post re. ADSL2+ (which is what I will be having). Is the modem as flakey for that as it is for VDSL? Thankfully I've not bought it yet and I checked here before hitting the checkout button.

Seems like the Billion 8800AXL will be the best choice at the moment.
 
Kiro-San said:
Reading through the thread it seems most of the problems seem VDSL related, but I've only seen the odd post re. ADSL2+ (which is what I will be having). Is the modem as flakey for that as it is for VDSL? Thankfully I've not bought it yet and I checked here before hitting the checkout button.

Seems like the Billion 8800AXL will be the best choice at the moment.
Click to expand...

EDIT: Test concluded. After 4 hours the FEC has started exponentially rising :(. I will try this out on fastpath later this evening with the same agc_vref, but I doubt it's going to help long term.
 
Kiro-San said:
Reading through the thread it seems most of the problems seem VDSL related, but I've only seen the odd post re. ADSL2+ (which is what I will be having). Is the modem as flakey for that as it is for VDSL? Thankfully I've not bought it yet and I checked here before hitting the checkout button.

Seems like the Billion 8800AXL will be the best choice at the moment.
Click to expand...

From what I've read there is far more success with this modem and adsl...
 
FEC value

Firmware 2139.

The good news:
Uptime: 9 days 6 hours 9 minutes 58 seconds so no syncs. 35 CRC down, 455 CRC up.

The disappointing news:
Still connecting at a max of 64Mb/s when using Speedtest. Hasn't varied in nine days and was 68Mb/s when on HH5 and the line was stable.

The big number:
FEC Download count is an incredible 1,551,873,674 - 1,940 FEC per second.

The baffling number:
Interleave depth reported as being 1033 according to stats. It hasn't changed in 9+ days.
 
sumowesley said:
Firmware 2139.

The good news:
Uptime: 9 days 6 hours 9 minutes 58 seconds so no syncs. 35 CRC down, 455 CRC up.

The disappointing news:
Still connecting at a max of 64Mb/s when using Speedtest. Hasn't varied in nine days and was 68Mb/s when on HH5 and the line was stable.

The big number:
FEC Download count is an incredible 1,551,873,674 - 1,940 FEC per second.

The baffling number:
Interleave depth reported as being 1033 according to stats. It hasn't changed in 9+ days.
Click to expand...

The FEC is a strange thing. It's humungous here too. I initially had a reasonable FEC until 4 hours uptime~ then boom - thinking that lowering AGC vref had fixed it. I will be attempting fastpath at 6dB with a lower AGC vref later this evening, but I don't hold high hopes that CRC's will spike or pour in within minutes of syncing. So far the only way I've managed to keep a stable and mostly error free connection is connecting with INP 3 or higher and a delay of 8ms or higher, fastpath attempts have previously failed to maintain a stable and mostly low error connection.
 
I telneted into in to my router this evening to retrieve the modem stats. I'm also suffering from insanely high FEC Down errors (1975 per second). Also I'm guessing the interleave depth of 2565 means I am in fact not on Fastpath as the status page is reporting.

Does anyone know if the FEC Errors are something to be concerned about? The info on Kitz indicates that high FECs are expected on interleaved lines:
http://www.kitz.co.uk/adsl/linestats_errors.htm

Code: 
admin@DSL-AC68U:/tmp/adsl# cat info_adsl.txt
outDiscards=22
inDiscards=40
outBytes=468227420
inBytes=518150752
outPkts=3291145
inPkts=4387152
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.1 dB
AttenDown=18.6 dB
SNRMarginUp=6.0 dB
AttenUp=0.4 dB
DataRateDown=22398 kbps
DataRateUp=9035 kbps
WanListMode=1
FECDown=1092971783
FECUp=897
CRCDown=154
CRCUp=136
HECDown=0
HECUp=0
ADSLUpTime=6 days,  9:42, 54 secs
ADSLActiveTime=0 min, 16 secs
PowerDown=12.4 dbm
PowerUp=5.2 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=9147
AttainDown=57848
ShowtimeStart=16
TotalStart=33
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=2565
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
admin@DSL-AC68U:/tmp/adsl#
 
Last edited:
Meant to show latest speeds:
3928734372.png
 
Here are the results from last night until now, with an agc_vref setting of 300 300 300 300.

Code: 
near-end path0 crc:    8715(758)
near-end fec sec:       275(21315)
near-end err sec:       268(347)
near-end ses sec:       22(36)
near-end los sec:       0(0)
near-end ua  sec:       32(289)
far-end path0 fec:      4601(155675)
far-end path0 crc:      0(1120)
far-end fec sec:        48(4224)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(276)
far-end ua  sec:        0(13649)
outPkts=7828964
inPkts=10296575
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=72204 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=79164
FECUp=4601
CRCDown=8715
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 7:30, 15 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.0 dbm
PowerUp=4.8 dbm
AttainUp=25872
AttainDown=86380
ShowtimeStart=19
TotalStart=5296
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

Had a burst of errors during the uptime somewhere, other than that it was mostly trickling of CRC's (around a rate of 1 every 2-3 minutes, which is about normal for my line at this speed :x).

The above was fastpath (INP 0, delay 1ms) with a target SNRM of 9.0 dB.

I've now reduced the target SNRM to 7.0 dB, the agc_vref setting to 250 250 200 250, and have increased delay to 3ms while keeping INP at 0. Will post results later today.

On the previous connection I would've lost sync usually long before the 7 hour uptime.
 
simoncraddock said:
If BT are monitoring your DSLAM they will be wondering what the heck is going on lol.
Click to expand...

Claim it's a faulty modem in the router? lol - Nah I expect they just rely on automated systems such as DLM. I think I'm improving the stability of this device though. Once I've solved the stability somewhat (if I can) then I'll probably return to the parameters that DLM has set and let it control. If however it keeps me on the speed banding for an enternity then I may well override it and use the parameters that I know my line can support.
 
sumowesley said:
I had read the Kitz description before and not really worried but 1900+ of anything per second on average is a huge overhead in processing surely?
Click to expand...

FEC error correction is quite low level so I don't think the correction will be processed by a CPU....more likely to be hard logic in the modem ASIC, so wouldn't really affect performance.

The thing is, I have no idea what constitutes a normal rate of correction....and since in this case it's correcting errors in the download data, does that mean the modem really has any control of FEC? If it's correcting errors occurring on the line from the DSLM surely the crappyness of the modem shouldn't make any difference?

Interleaving is also intimately linked to FEC. From my (admittedly limited) understanding, interleaving is a way of spreading out the FEC correction bits across multiple symbols. That's why ping times increase because the data has to go through a buffer that spreads out correction bits for earlier symbols to later symbols....adding a bit of lag into the system.

I assume that the line can be optionally interleaved in both directions so is it possible that the ASUS modem is not correctly interleaving the TX data? If that were the case it could cause massive error rates in the DSLM triggering DLM?

Actually does anyone know how the speeds are negotiated with the DSLM? My Rx connection rate has been hit hard by DLM but my Tx connection rate hasn't been affected....Does the DSLM set a download speed but let the modem set the upload speed? Seems like a weird way to negotiate a connection though. Probably need to do some more reading about this stuff if info is available.
 
IronRod said:
FEC error correction is quite low level so I don't think the correction will be processed by a CPU....more likely to be hard logic in the modem ASIC, so wouldn't really affect performance.

The thing is, I have no idea what constitutes a normal rate of correction....and since in this case it's correcting errors in the download data, does that mean the modem really has any control of FEC? If it's correcting errors occurring on the line from the DSLM surely the crappyness of the modem shouldn't make any difference?

Interleaving is also intimately linked to FEC. From my (admittedly limited) understanding, interleaving is a way of spreading out the FEC correction bits across multiple symbols. That's why ping times increase because the data has to go through a buffer that spreads out correction bits for earlier symbols to later symbols....adding a bit of lag into the system.

I assume that the line can be optionally interleaved in both directions so is it possible that the ASUS modem is not correctly interleaving the TX data? If that were the case it could cause massive error rates in the DSLM triggering DLM?

Actually does anyone know how the speeds are negotiated with the DSLM? My Rx connection rate has been hit hard by DLM but my Tx connection rate hasn't been affected....Does the DSLM set a download speed but let the modem set the upload speed? Seems like a weird way to negotiate a connection though. Probably need to do some more reading about this stuff if info is available.
Click to expand...

The DSLAM has a minimum and maximum sync rate for downstream and upstream. It also has parameters for controlling the minimum INP and the delay in either direction (interleaving). The modem's chipset for this specific device does have the ability to ignore the parameters specific to downstream. For example, I can specify fastpath even if the DSLAM wants an INP of 3 and a delay of 8ms, I can also specify a different minimum and maximum downstream sync rate that is beyond the limits of the DSLAM. The modem doesn't negotiate the maximum and minimum sync rate normally, but it will sync up to the maximum and minimum sync rate specified by the DSLAM, subject to the target SNRM set at the DSLAM of course.

A connection can be optionally interleaved in either direction, so even if downstream is interleaved but the upstream is fastpath that shouldn't be linked to the massive error rates seen on this device (e.g. high FEC on the downstream). On my own connection the DSLAM has set the upstream to an INP of 4 and a delay of 8ms at the moment. I've overridden the DSLAM's downstream parameters of a minimum sync rate of 25Mbps and a maximum sync rate of 49Mbps with an INP of 3 and a delay of 8ms, with a min/max sync rate of 40Mbps/80Mbps with an INP of 0 and a delay of currently 3ms.

So far reducing the 'Rx AGC Gain Adjustment' (or agc_vref - meaning AGC's voltage reference I believe) to a value much less than the GUI's settings has made the connection much more stable here (including the disabled option which sets 65535 but actually makes the modem set 440 internally - a default assumably). It's still early days but I usually couldn't hold this sort of sync rate on with no INP and an almost fastpath delay for more than 10 minutes. See below for statistics.

AGC vref = 250 250 200 250
Code: 
>tcapi get Info_Adsl lineState;tcapi show Info_Adsl;wan vdsl2 show mgcnt
up
near-end path0 fec:     243952(59958960)
1near-end path0 crc:    1010(1561)
near-end fec sec:       3938(25246)
near-end err sec:       237(577)
near-end ses sec:       9(46)
near-end los sec:       0(0)
near-end ua  sec:       0(319)
far-end path0 fec:      4907(160582)
far-end path0 crc:      0(1120)
7far-end fec sec:       55(4280)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(279)
far-end ua  sec:        0(13678)
outDiscards=322
inDiscards=3607
outBytes=2504385204
inBytes=36182088
outPkts=10749257
inPkts=13927832
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=7.0 dB
AttenDown=10.4 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=79997 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=243952
FECUp=4907
CRCDown=1010
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 6:56, 26 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.7 dbm
PowerUp=4.6 dbm
AttainUp=26112
AttainDown=97020
ShowtimeStart=19
TotalStart=5315
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=191
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

So my current theory is that perhaps the AGC vref value is just simply set too high for VDSL2 connections on this modem. Time will tell, but so far this has kept my connection up for much longer than it would previously stay connected for, with significantly less CRC errors.

I may be nudging it down to '200 200 200 200' this evening, with 1ms delay (fastpath).
 
FEC discussion

But how many of us out there have the capability to a) understand what low level changes are needed based on the data and b) want to setup the console mechanism to allow those changes to be made?

I thought my original ambition of plugging it in and, having told it that I had a BT Infinity system, would be enough for it to do its own calculations based on how it found my line.

Way too much time and effort is being given by the community to something that should just work.
 
sumowesley said:
But how many of us out there have the capability to a) understand what low level changes are needed based on the data and b) want to setup the console mechanism to allow those changes to be made?

I thought my original ambition of plugging it in and, having told it that I had a BT Infinity system, would be enough for it to do its own calculations based on how it found my line.

Way too much time and effort is being given by the community to something that should just work.
Click to expand...

Yeah. I know, it should just be a device that can just work out of the box and the advanced changes optional. I don't expect stability to last, nor ASUS to solve the cause of the problems a good number of people are having, in which case my only other options are to either sell mine on the famous auction website or store it and just keep it as a backup ethernet router only (an expensive piece of plastic pretty much).

EDIT: Speak of the devil, just as I posted this reply the connection died. Hmm... disappointing. I think it's time to give up and decide on what fate mine has.

Does the N66U have all these problems still or did ASUS resolve it?
 
Last edited:
11 days an one hour on firmware 2139 with no DSL resets.

39 download CRC
522 upload CRC
FEC count so high I nearly fainted (1,861,979,341 = 1950 FEC per second)

Absolutely no change at all in line speeds in that time.
 
You must log in or register to reply here.
Back
Top Bottom