Anyone Using an Asus DSL-AC68U

Ixel said:
I see. My FEC has just started going up quite a bit again, connection remains fine however and error seconds and CRC very reasonable. ASUS however, as I understand it, feel that the abnormally high FEC in comparison to other devices is fine.
Click to expand...

I've seen just as many reports of high FEC with other modems, Google it....
 
chriscatt said:
I've seen just as many reports of high FEC with other modems, Google it....
Click to expand...

I'm basing my comparison on modems I've used in the past on my line, e.g. devices when on interleaving that I've used such as Cisco 887VA, Fritz!Box 7390 and HG612 (excluding ECI as stats are unreliable from that device I've found). This is certainly a record breaker here and some others on this thread have also observed a similar result with their DSL-AC68U.

Anyway, still going good, FEC seconds is counting more often now (not every second still however) but the actual amount it's rising by is still good and not insanely going out of control (e.g. thousands of FEC per second continuously).

Cut down summary of the stats so far
Code: 
near-end path0 fec:     315139(567093)
near-end path0 crc:     55(63)
near-end fec sec:       939(1112)
near-end err sec:       21(24)

fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=10.4 dB
SNRMarginUp=12.5 dB
AttenUp=0.1 dB
DataRateDown=74174 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=315139
FECUp=0
CRCDown=55
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 6:52, 32 secs
 
Using either my HG612 or ZXYEL VMG8324-B10A over a test period of 12hrs they would record on average 200,000+ FEC errors. Yet the Asus would record over the same time almost 2 million, thats 100X more errors. I still believe that it was this that was causing DLM to keep increasing interleaving depth every few days because CRC levels were only in the single or double digits as were ES and SES.

I asked Asus about this, in fact I think I was probably the first person to notice this way back early November and report it. Asus never replied about this, and I emailed them 3 times on the very subject.

Either the firmware is reporting incorrectly or the Mediatek CPE is the problem, either way they still seem to refuse to want to discuss it which is suspicious.
 
simoncraddock said:
Using either my HG612 or ZXYEL VMG8324-B10A over a test period of 12hrs they would record on average 200,000+ FEC errors. Yet the Asus would record over the same time almost 2 million, thats 100X more errors. I still believe that it was this that was causing DLM to keep increasing interleaving depth every few days because CRC levels were only in the single or double digits as were ES and SES.

I asked Asus about this, in fact I think I was probably the first person to notice this way back early November and report it. Asus never replied about this, and I emailed them 3 times on the very subject.

Either the firmware is reporting incorrectly or the Mediatek CPE is the problem, either way they still seem to refuse to want to discuss it which is suspicious.
Click to expand...

Yes, it can't be right. As for DLM monitoring FEC, I'm still undecided. Kitz I believe concluded that FEC isn't considered by DLM's decisioning, but I'm still wondering in the back of my mind if it's considered. I'm also wondering if I've stumbled into a setting via TC which has resolved the abnormally high FEC. I'll post another set of results in a few hours (or sooner if it turns out that it's doing it again).
 
Ixel said:
Yes, it can't be right. As for DLM monitoring FEC, I'm still undecided. Kitz I believe concluded that FEC isn't considered by DLM's decisioning, but I'm still wondering in the back of my mind if it's considered. I'm also wondering if I've stumbled into a setting via TC which has resolved the abnormally high FEC. I'll post another set of results in a few hours (or sooner if it turns out that it's doing it again).
Click to expand...

I went back to the ECI OR modem and RT-AC68U on Thursday; this morning DLM has put me back onto fastpath downstream (8ms removed from ping times - need to restart the router to get the new IP profile and back to full speed for my line).

Difficult to do an exact comparison as I can't see the ECI stats, but the fact DLM moved back to fastpath so quickly indicates there's still something fundamentally wrong with the DSL-AC68U even working in interleaved mode and maybe the FEC count is considered by DLM. That's assuming that the ECI was generating fewer FEC during the time I've had it reconnected.
 
Ixel said:
Yes, it can't be right. As for DLM monitoring FEC, I'm still undecided. Kitz I believe concluded that FEC isn't considered by DLM's decisioning, but I'm still wondering in the back of my mind if it's considered. I'm also wondering if I've stumbled into a setting via TC which has resolved the abnormally high FEC. I'll post another set of results in a few hours (or sooner if it turns out that it's doing it again).
Click to expand...

I also have a suspicion that the high attainable rate is contributing to this.

I have in my possession a HH5, OR HG612, OR ECI, ZYXEL VMG8324, BIPAC 8800nl, all these show my attainable rate as between 64/22 and 68/22. Now the Asus would be from memory be anything between 85/24 and 88/26, even higher if I dropped the SNRM to 5db. Again this is something Asus when asked refused to answer.

After 6 months Asus still haven't fixed what should have been an 'out the box working all-in-one' solution many wanted yet still seems to be in it's early test stages. The same goes for the other Asus modems using the Mediatek CPE, very powerful but so un-stable and un-predictable.

My conclusion is they need to release a firmware solely for the UK, stripped of any algorithms, annex modes etc not used in the UK and work from that point based on BTs ADSL/VDSL requirements only rather than being a single firmware for the entire world.
 
simoncraddock said:
I also have a suspicion that the high attainable rate is contributing to this.

I have in my possession a HH5, OR HG612, OR ECI, ZYXEL VMG8324, BIPAC 8800nl, all these show my attainable rate as between 64/22 and 68/22. Now the Asus would be from memory be anything between 85/24 and 88/26, even higher if I dropped the SNRM to 5db. Again this is something Asus when asked refused to answer.

After 6 months Asus still haven't fixed what should have been an 'out the box working all-in-one' solution many wanted yet still seems to be in it's early test stages. The same goes for the other Asus modems using the Mediatek CPE, very powerful but so un-stable and un-predictable.

My conclusion is they need to release a firmware solely for the UK, stripped of any algorithms, annex modes etc not used in the UK and work from that point based on BTs ADSL/VDSL requirements only rather than being a single firmware for the entire world.
Click to expand...

One thing I've observed regarding the attainable, e.g. in comparison to the HG612, is that the HG612 will calculate the attainable rate up to the target SNRM (6dB), where the ASUS looks like it's calculating it to an estimated value around 0dB SNRM. This may also be why it appears so much higher.
 
Ixel said:
One thing I've observed regarding the attainable, e.g. in comparison to the HG612, is that the HG612 will calculate the attainable rate up to the target SNRM (6dB), where the ASUS looks like it's calculating it to an estimated value around 0dB SNRM. This may also be why it appears so much higher.
Click to expand...

If that's true then maybe the VDSL SNRM stability setting should be set to 6db+ to compensate if it's using 0db as a base figure.

Just a theory, the Asus whilst I had it always reported the wrong interleaving level, often higher than it really was in comparison to another modem. Could this be the cause of the high FEC count? Might be worth re-checking, they know it reports fastpath incorrectly.
 
Last edited:
simoncraddock said:
If that's true then maybe the VDSL SNRM stability setting should be set to 6db+ to compensate if it's using 0db as a base figure.

Just a theory, the Asus whilst I had it always reported the wrong interleaving level, often higher than it really was in comparison to another modem. Could this be the cause?
Click to expand...

You might be right, not sure now. When I next try fastpath again I will see what it says and post here. FEC just started counting every second now, but the FEC delta is still very much what I'd expect (around 1000 per minute, instead of previously nearly 2000 per second - so far) :).

EDIT 1:
FEC has stopped continuously counting.
 
Last edited:
Ixel said:
Either I've stumbled into a setting via TC that has fixed the FEC abnormally counting upwards into millions within a short timeframe, or I'm being very lucky at the moment. Last night I played with some more settings to see what effect they would have basically.

Code: 
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec:     306051(558005)
near-end path0 crc:     44(52)
near-end fec sec:       505(678)
near-end err sec:       17(20)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(31)
far-end path0 fec:      0(0)
far-end path0 crc:      0(0)
far-end fec sec:        0(0)
far-end err sec:        0(0)
far-end ses sec:        0(0)
far-end los sec:        0(0)
far-end ua  sec:        0(0)
outDiscards=33
inDiscards=94
outBytes=315162019
inBytes=870824259
outPkts=1213614
inPkts=1209176
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=10.4 dB
SNRMarginUp=12.5 dB
AttenUp=0.1 dB
DataRateDown=74174 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=306051
FECUp=0
CRCDown=44
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 5:51, 1 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=6.1 dbm
AttainUp=29592
AttainDown=99540
ShowtimeStart=19
TotalStart=39
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=333
AdslStandard=VDSL2
AdslType=ANNEX_B

This is the longest uptime I've had without the FEC counting every second of uptime and going upwards in an abnormal manner. I'll update later, fingers crossed.
Click to expand...

Nice one, you'll have to keep us posted. Are you still feeding back to Paul Lee?
 
sga1111 said:
Nice one, you'll have to keep us posted. Are you still feeding back to Paul Lee?
Click to expand...

Indeed. At the moment I'm not, but once I have something conclusive to share with Paul Lee/ASUS then I will. I need to be absolutely sure I've stumbled into a fix for the abnormal FEC, and if I have then how does this also effect fastpath (e.g. perhaps CRC's are much less too). FEC is still fine.

Code: 
near-end path0 fec:     361972(613926)
near-end path0 crc:     100(108)
near-end fec sec:       1881(2054)
near-end err sec:       36(39)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(31)

fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=10.4 dB
SNRMarginUp=12.5 dB
AttenUp=0.1 dB
DataRateDown=74174 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=361972
FECUp=0
CRCDown=100
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 9:52, 26 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=6.1 dbm
AttainUp=29585
AttainDown=99760

EDIT 1:
All good things come to an end :(. Lasted longer, but didn't hold. FEC is going wild now, CRC's remain low so I will try fastpath this evening and also check the attainable rate.
 
Last edited:
Ixel said:
Indeed. At the moment I'm not, but once I have something conclusive to share with Paul Lee/ASUS then I will. I need to be absolutely sure I've stumbled into a fix for the abnormal FEC, and if I have then how does this also effect fastpath (e.g. perhaps CRC's are much less too). FEC is still fine.

Code: 
near-end path0 fec:     361972(613926)
near-end path0 crc:     100(108)
near-end fec sec:       1881(2054)
near-end err sec:       36(39)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(31)

fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=10.4 dB
SNRMarginUp=12.5 dB
AttenUp=0.1 dB
DataRateDown=74174 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=361972
FECUp=0
CRCDown=100
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 9:52, 26 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=6.1 dbm
AttainUp=29585
AttainDown=99760
Click to expand...

Ineresting reading though, fingers crossed you've found it. You still working with the ferrites on?
 
sga1111 said:
Ineresting reading though, fingers crossed you've found it. You still working with the ferrites on?
Click to expand...

Yes. Unfortunately FEC has now gone wild. CRC's remain low however (downstream set to INP 1, delay 4ms - a very light level of interleaving). I'll try fastpath with this current setup this evening.
 
chriscatt said:
http://community.plus.net/forum/index.php/topic,94190.0.html/


https://community.bt.com/t5/Other-Broadband-Queries/Very-very-high-FEC-Errors/td-p/398099

http://forums.digitalspy.co.uk/showthread.php?t=637631

There does seem to be a lot having several millions of fec errors and they are being told not to worry about them...
Click to expand...

The first two remind me of a bug that caused the highest number to be shown on the stats for any duration of the connection. The third one is similar to here though. Fair enough, I'll ignore the FEC then and just see whether or not I can get this thing stable on fastpath then (ultimately). To do that I'll also use the same sync rate I had on the ECI /r before using the ASUS (74Mbps banded downstream, fastpath), then it's a fair test and comparison to work with. Wish me luck ;).
 
Been running 2155 for a few days now. Stayed up for over 2 days with no problem. I re synced this morning at 5db target but also changed the vdsl profile to 17a rather than 30 and had fewer crc errors compared to the previous sync.

Is it possible to get a 4 db target as 5 is the lowest on the gui?
 
Guys - remember that FEC stands for forward error correction. This number refers to the number of errors that HAVE been corrected and should not be referred to as errors as such. A high FEC means that for what error reason, the modem has had to and has CORRECTED more errors.

FEC goes hand in hand with interleaving.
 
Last edited:
ardsar said:
Guys - remember that FEC stands for forward error correction. This number refers to the number of errors that HAVE been corrected and should not be referred to as errors as such. A high FEC means that for what error reason, the modem has had to and has CORRECTED more errors.

FEC goes hand in hand with interleaving.
Click to expand...

Which is fine in theory, however when the router racks up 300,000 errors in 3 minutes whilst the connection isn't being used for anything significant, that to me says there's a problem.

In just over 2 hours connection time, I had 6.6million FEC - it doesn't inspire confidence in this particular router.
 
Evil Shubunkin said:
Which is fine in theory, however when the router racks up 300,000 errors in 3 minutes whilst the connection isn't being used for anything significant, that to me says there's a problem.

In just over 2 hours connection time, I had 6.6million FEC - it doesn't inspire confidence in this particular router.
Click to expand...

i didn't say there was not a problem with the modem - clearly there is - I returned mine a couple of weeks ago after it killed my download speeds - which I am still suffering from.
 
Evil Shubunkin said:
Which is fine in theory, however when the router racks up 300,000 errors in 3 minutes whilst the connection isn't being used for anything significant, that to me says there's a problem.

In just over 2 hours connection time, I had 6.6million FEC - it doesn't inspire confidence in this particular router.
Click to expand...

I had a similar amount of errors with a Draytek 2860, something like 160 million a day. It knackered my connection for months. I've since switched to a Billion 8800NL and I get around 20,000 a day now and my sync speeds are recovering.
 
You must log in or register to reply here.
Back
Top Bottom