Its starting to show up on the support site now. Thanks for the heads up.
Anyone Using an Asus DSL-AC68U
- Thread starter Socrates470BC
- Start date
Its starting to show up on the support site now. Thanks for the heads up.
How is going this firmware with vdsl guys
This firmware managed to drop my snr from 25 db (set by isp due to my capped profile-adsl) down to 5 and had disconnections
Lots of errors as well for my adsl profile
I guess this firmware must dedicated for vdsl?
This firmware managed to drop my snr from 25 db (set by isp due to my capped profile-adsl) down to 5 and had disconnections
Lots of errors as well for my adsl profile
I guess this firmware must dedicated for vdsl?
Last edited:
Just installed. I'll stay on 49Mbps at INP 3 with a delay of 8ms for the next 9-12 hours (as set by DLM) and observe if the FEC count rockets upwards later on.
EDIT 1:
Path mode is mis-reporting as fastpath when it should say interleaved. I guess it's looking at the upstream and not the downstream.
EDIT 1:
Path mode is mis-reporting as fastpath when it should say interleaved. I guess it's looking at the upstream and not the downstream.
Last edited:
Associate
- Joined
- 29 Sep 2014
- Posts
- 64
Firmware 2155 has been applied.
It must say something that my most visited URL is my Asus Router and the second most visited URL is this thread.
It must say something that my most visited URL is my Asus Router and the second most visited URL is this thread.
Associate
- Joined
- 11 Jul 2011
- Posts
- 178
- Location
- Aberdeen
FW: 2155
Downstream is interleaved / upstream on fastpath.
Uptime (hh:mm) - FEC Down/UP
0:15 - 0000477/0
0:49 - 0045804/2
1:12 - 0061585/2
1:18 - 0072054/2
1:25 - 0657286/2
1:33 - 1717597/2
1:36 - 2140755/2
1:39 - 2437419/2 (sitting typing this post)
EDIT:
2:11 - 6614844/4
And I'm not doing anything that is using 100% bandwidth on the line so there shouldn't be that many packets needing corrected.
I wonder if the counter is getting itself in a tizz quickly and doing something weird with the numbers?
Is anyone certain that FEC is ignored by DLM? As there doesn't appear to be any noticeable impact on my line at the moment with the FEC increasing at the rate it is, so I am tempted to leave the router and see how it goes. Otherwise it's back to the OR modem and RT-AC68U for time being to get me back onto fastpath in the near future.
Downstream is interleaved / upstream on fastpath.
Uptime (hh:mm) - FEC Down/UP
0:15 - 0000477/0
0:49 - 0045804/2
1:12 - 0061585/2
1:18 - 0072054/2
1:25 - 0657286/2
1:33 - 1717597/2
1:36 - 2140755/2
1:39 - 2437419/2 (sitting typing this post)
EDIT:
2:11 - 6614844/4
And I'm not doing anything that is using 100% bandwidth on the line so there shouldn't be that many packets needing corrected.
I wonder if the counter is getting itself in a tizz quickly and doing something weird with the numbers?
Is anyone certain that FEC is ignored by DLM? As there doesn't appear to be any noticeable impact on my line at the moment with the FEC increasing at the rate it is, so I am tempted to leave the router and see how it goes. Otherwise it's back to the OR modem and RT-AC68U for time being to get me back onto fastpath in the near future.
Last edited:
As far as I understand, kitz concluded in her research into FTTC's DLM that the DLM doesn't observe FEC. I may be wrong though.
Firmware 2155 so far hasn't shown much difference in connection stability on fastpath at a lower SNRM. I can't help but observe that Australia's FTTC seems to use a 12dB target SNRM, and some other countries use a 9dB target SNRM.
Anyway, at either of those targets on fastpath I still got an occasional spike of CRC errors. So, I'm now trying up to 80Mbps on near fastpath (INP 1, delay 3ms) with an initial target SNRM of 12dB downstream and a potentially quicker reacting/more aggressive bitswap. This results a very slight loss in speed, though if I nudge the delay up 1-2ms I will gain more speed. The attainable rate is nothing to go by as it's just an estimated calculation, SNRM is what matters and counts.
So far the FEC hasn't gone wild and started counting every second of uptime, which isn't something I'd expect nor have I seen happen on any other DSL device I've used. TC is still available which is nice for me.
3:29pm
Anyway, at either of those targets on fastpath I still got an occasional spike of CRC errors. So, I'm now trying up to 80Mbps on near fastpath (INP 1, delay 3ms) with an initial target SNRM of 12dB downstream and a potentially quicker reacting/more aggressive bitswap. This results a very slight loss in speed, though if I nudge the delay up 1-2ms I will gain more speed. The attainable rate is nothing to go by as it's just an estimated calculation, SNRM is what matters and counts.
So far the FEC hasn't gone wild and started counting every second of uptime, which isn't something I'd expect nor have I seen happen on any other DSL device I've used. TC is still available which is nice for me.
Code:
new bs target_snrm = 12. 0(dB) bs trigger snrm diff = 0.75(dB)
new bs snr_record_tone_num = 128 bs wait_num = 1
new bs scan_start_tblidx = 1 bs scan_end_tblidx = 256
Code:
near-end path0 fec: 23020(62910742)
near-end path0 crc: 70(308)
near-end fec sec: 413(35441)
near-end err sec: 26(165)
near-end ses sec: 0(16)
near-end los sec: 0(0)
near-end ua sec: 0(100)
far-end path0 fec: 42(358967)
far-end path0 crc: 8(1503)
far-end fec sec: 12(6381)
far-end err sec: 8(1131)
far-end ses sec: 0(0)
far-end los sec: 0(487)
far-end ua sec: 0(21117)
outDiscards=1085
inDiscards=179
outBytes=2567153189
inBytes=1553279937
outPkts=9278895
inPkts=10825129
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=11.9 dB
AttenDown=10.4 dB
SNRMarginUp=12.3 dB
AttenUp=0.1 dB
DataRateDown=62138 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=23020
FECUp=42
CRCDown=70
CRCUp=8
HECDown=0
HECUp=0
ADSLUpTime= 3:21, 32 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=6.4 dbm
AttainUp=28874
AttainDown=89360
ShowtimeStart=19
TotalStart=77
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=395
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus3:29pm
Code:
near-end path0 fec: 56426(62944148)
near-end path0 crc: 118(356)
near-end fec sec: 824(35852)
near-end err sec: 46(185)
near-end ses sec: 0(16)
near-end los sec: 0(0)
near-end ua sec: 0(100)
far-end path0 fec: 76(359001)
far-end path0 crc: 12(1507)
far-end fec sec: 22(6391)
far-end err sec: 12(1135)
far-end ses sec: 0(0)
far-end los sec: 0(487)
far-end ua sec: 0(21117)
outDiscards=1497
inDiscards=205
outBytes=2946772450
inBytes=2502817280
outPkts=10540939
inPkts=12235897
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=11.9 dB
AttenDown=10.4 dB
SNRMarginUp=12.3 dB
AttenUp=0.1 dB
DataRateDown=62138 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=56426
FECUp=76
CRCDown=118
CRCUp=12
HECDown=0
HECUp=0
ADSLUpTime= 6:29, 1 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=6.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=28905
AttainDown=89352
ShowtimeStart=19
TotalStart=77
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=395
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Last edited:
Associate
- Joined
- 29 Sep 2014
- Posts
- 64
Just over a day of firmware 2155
Code:
outDiscards=941
inDiscards=4
outBytes=709428603
inBytes=1994061618
outPkts=4598268
inPkts=3625324
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.3 dB
SNRMarginUp=6.2 dB
AttenUp=0.1 dB
DataRateDown=69741 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=173582602
FECUp=2210
CRCDown=9
CRCUp=118
HECDown=0
HECUp=0
ADSLUpTime=1 day, 25 min, 32 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.3 dbm
PowerUp=4.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=20993
AttainDown=101580
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1024
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)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.
Associate
- Joined
- 29 Sep 2014
- Posts
- 64
The figure worries me although I have nothing to compare it against. 1972 corrected errors every second seems a huge number.
Since going back to the Asus and have just that on my line for the over the last 3/4 firmware versions, my speed has remained at a pretty much constant 64Mbps down. If FEC has been ignored AND DLM is back again, I would have expected there to be a shift one way or the other but nothing has happened.
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
DLM is indeed back on-line, it triggered a 7mbps increase on my DS yesterday.
Hi all, first post here, but hope you can all help. have a DSL-N66U and believe the DSL modem is the same as in the AC68U.
Having same issues as all of you plus now on interleaving and speed dropped, trying all the suggestions on here, and about to try the ferrite beads.
but a few things I have noticed, old openreach modem was using 17a profile annex B, but N66U was using Annex a , also even when I set to force Annex B still say's Annex A in DSL log? fault or am I on B anyway of checking?
Also if Ixel is available to help, saw you can switch interleaving and fastpath on and off and adjust the speed, would the commands you have found be the same for the N66U? as would be good to see if my modding is working, not sure if we can get some dialogue going in private, info would not be passed on only for my testing!
Thanks!
Associate
- Joined
- 29 Sep 2014
- Posts
- 64
If that is the case, I don't understand why my line has not been changed over the three or four weeks of this cycle of firmware updates. The nagging doubt in my mind is that the HH5 would ultimately lead to a quicker line than the Asus. After all, I was at a constant 68Mbps with the HH5 before moving back to the Asus. Thrilled though I am to have it relatively stable, I still can't help but feel I'm cheating myself by keeping it going. I check the damn thing many times a day - I shouldn't even have to remember I have a router, let alone keep checking it to make sure it hasn't gone CRC happy.
Associate
- Joined
- 11 Jul 2011
- Posts
- 178
- Location
- Aberdeen
I think you need a period of continuous connection before DLM will kick in - looking above, your uptime was 1 day something so that may have reset the counter DLM uses before it will consider making changes.
http://community.plus.net/library/browsing/fttc-dlm-what-it-is-how-it-works/ has a good explanation although isn't clear if a single disconnect on a day would cause the counter to reset.
Associate
- Joined
- 29 Sep 2014
- Posts
- 64
The cynic in me believes a single disconnect may affect the counters in a bad way. There was an 11 day period of connection with a previous firmware (2144 I think) but perhaps that took it into the DLM not being active period.
Maybe I'm not helping myself by refusing connections from pbthdm.bt.mo - just didn't want any attempt at TR-069 playing havoc with a very delicate Asus device.
Maybe I'm not helping myself by refusing connections from pbthdm.bt.mo - just didn't want any attempt at TR-069 playing havoc with a very delicate Asus device.
Last edited:
I'm late to this thread, but thought it might be worth posting my experience and current statistics.
I got my DSL-AC68U in early September for use with a UK ISP. I found VDSL stability to be poor (resync at least once a day) with initial firmware and default settings.
3.0.0.4.376_2072 was released a few days after I got the router and I've been using it since. (I see 3.0.0.4.376_2155 has just been released but haven't upgraded yet)
I got long term stability (50+ days) by setting the noise margin to 10dB. At the beginning of the 50 day period, the measured downstream SNR was about 10dB, although it's now about 14 (colder weather?).
I'm not sure what to conclude about the number of CRC errors over this period.
Here are the statistics and settings: http://i.imgur.com/OEDvVJc.png
Please reply with any comments.
I got my DSL-AC68U in early September for use with a UK ISP. I found VDSL stability to be poor (resync at least once a day) with initial firmware and default settings.
3.0.0.4.376_2072 was released a few days after I got the router and I've been using it since. (I see 3.0.0.4.376_2155 has just been released but haven't upgraded yet)
I got long term stability (50+ days) by setting the noise margin to 10dB. At the beginning of the 50 day period, the measured downstream SNR was about 10dB, although it's now about 14 (colder weather?).
I'm not sure what to conclude about the number of CRC errors over this period.
Here are the statistics and settings: http://i.imgur.com/OEDvVJc.png
Please reply with any comments.
Last edited:
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
Looks like you preferred to sacrifice speed over stability as your DS is considerably slower than it should be looking at your attainable rate. I could have done that but why should I compromise simply because the device is unstable.
How is going this firmware with vdsl guys
This firmware managed to drop my snr from 25 db (set by isp due to my capped profile-adsl) down to 5 and had disconnections
Lots of errors as well for my adsl profile
I guess this firmware must dedicated for vdsl?
I start thinking if is the the SRA can not keep correct the stability
Since the snr dropped (adsl line) i only have disable SRA (bit swap still on-seems going well for my adsl connection with _2155) and the connection for peak time (saturday evening - can see how at the TBB monitor) is going well (stable)
Perhaps the asus for whatever reason (ferrite, busy time, rain etc) peaks noise and seems unable to recover easy due to wrong calculation of the SRA???
Last edited:
It looks like your connection is interleaved based on the ping to bbc.co.uk being higher than 10ms (typical average for fastpath). This may be helping to keep the device's connection stable. I've found it won't work well on pure fastpath with an SNRM of less than 12dB downstream.
---
I'm still tweaking mine, but I've adjusted the bitswap to be presumably more aggressive (VDSL2 only), and have imposed up to 80Mbps with a target SNRM of 9.0dB on INP of 1 and a delay of 4ms on the downstream (regardless of what DLM sets or has set). I did a minor adjustment earlier after holding around 24 hours of uptime with less than 100 ES on the downstream.
Code:
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec: 32763801(272182318)
near-end path0 crc: 54(869)
near-end fec sec: 15888(138298)
near-end err sec: 18(341)
near-end ses sec: 0(20)
near-end los sec: 0(0)
near-end ua sec: 0(160)
far-end path0 fec: 40(359382)
far-end path0 crc: 6(1562)
far-end fec sec: 10(6493)
far-end err sec: 5(1188)
far-end ses sec: 0(0)
far-end los sec: 0(493)
far-end ua sec: 0(21173)
outDiscards=446
inDiscards=780
outBytes=1893761352
inBytes=2272400449
outPkts=34057736
inPkts=35667892
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.3 dB
AttenUp=0.1 dB
DataRateDown=74261 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=32763801
FECUp=40
CRCDown=54
CRCUp=6
HECDown=0
HECUp=0
ADSLUpTime= 4:38, 8 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=6.2 dbm
AttainUp=29175
AttainDown=100132
ShowtimeStart=19
TotalStart=116
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=335
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplusPlease send me a message via 'trust' button.
Last edited:
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.
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.
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_BThis 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.
Last edited: