Oh, I see. It appears they haven't updated the 'others' section, when I checked the 'Windows 8.1 64bit' section I noticed the updated file and a restoration file for it.
Anyone Using an Asus DSL-AC68U
- Thread starter Socrates470BC
- Start date
Oh, I see. It appears they haven't updated the 'others' section, when I checked the 'Windows 8.1 64bit' section I noticed the updated file and a restoration file for it.
*Apologies for double post*
No. Killing the spectrum process stops the web UI showing the bitloading and SNRM graphs - as the spectrum process is responsible for querying the modem for that data. It will not skew your actual statistics such as CRC's, but should prevent the problem caused by the current 'spectrum' process.
Associate
- Joined
- 7 Jul 2009
- Posts
- 510
- Location
- Bristol, UK
Thanks. After another 20 minutes I can see the CRCs are now up to 6224 so they are still going with spectrum killed. I don't regularly use those graphs anyway so its fine to be disabled if I can get a stable line from doing so.
Fingers crossed this level of CRC errors doesnt upset DLM too much.
Fingers crossed this level of CRC errors doesnt upset DLM too much.
Strange, hopefully not. Can you paste your current stats? Curious to know what attenuation and such are. Trouble with only seeing CRC errors is you can't see what the UA seconds, errored seconds and severely errored seconds are
.
Associate
- Joined
- 7 Jul 2009
- Posts
- 510
- Location
- Bristol, UK
Just had a large jump. As I said, this line is rock solid on the HH5. I also have ferrites on the dsl and power cables coming into this box to try and reduce noise.
I have re-enabled TCM and after some hours of uptime and a disconnection then some more uptime and now dlm has re profiled my line, im back to interleave turned on and a very high fec count.
I think im going to turn TCM off after a fresh reboot. Is it fair to say after i make changes in TC, the router gui is not going to report correctly.
this is after enabling g.inp in gui
Code:
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec: 41247010(41679754)
near-end path0 crc: 2(1813)
near-end fec sec: 17626(19032)
near-end err sec: 1(939)
near-end ses sec: 0(82)
near-end los sec: 0(0)
near-end ua sec: 0(371)
far-end path0 fec: 76(59876)
far-end path0 crc: 0(361)
far-end fec sec: 10(2850)
far-end err sec: 0(123)
far-end ses sec: 0(0)
far-end los sec: 0(344)
far-end ua sec: 0(11507)
outDiscards=2520
inDiscards=17249
outBytes=3994615409
inBytes=2517303332
outPkts=10086599
inPkts=10727353
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.2 dB
SNRMarginUp=6.1 dB
AttenUp=0.1 dB
DataRateDown=66233 kbps
DataRateUp=19993 kbps
WanListMode=0
FECDown=41246780
FECUp=76
CRCDown=2
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 5:52, 37 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.6 dbm
PowerUp=3.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=20266
AttainDown=99516
ShowtimeStart=19
TotalStart=116
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=991
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)I think im going to turn TCM off after a fresh reboot. Is it fair to say after i make changes in TC, the router gui is not going to report correctly.
Code:
tc>wan vdsl2 show o_tps
=== O_TPS Msg ===
--- TPS-TC Capabilities ---
Mapped configurations of DS bearer channels and TPS-TC types
PTM-TC is mapped to DS bearer channel 0
DS bearer channel 1 is inactive
Mapped configurations of US bearer channels and TPS-TC types
PTM-TC is mapped to DS bearer channel 0
DS bearer channel 1 is inactive
Rate adaptation ratio of DS bearer channel 0 = 100
The whole excess capacity is allocated to bearer channel 0
DS bearer channel 0 configuration
Min_net_data_rate = 128 kbit/s
Max_net_data_rate = 74000 kbit/s
Rederved_net_data_rate = 0 kbit/s
Max_interleaving_delay = 8 ms
INP_min = 3 symbols
Dynamic interleaver reconfig(amd1) = N
INP no erasure = N
Pre-emption = N
Short packet = N
CIpolicy(amd1) = Mandatory
US bearer channel 0 configuration
Min_net_data_rate = 128 kbit/s
Max_net_data_rate = 20000 kbit/s
Rederved_net_data_rate = 0 kbit/s
Max_interleaving_delay = 8 ms
INP_min = 4 symbols
Dynamic interleaver reconfig(amd1) = N
INP no erasure = N
Pre-emption = N
Short packet = N
CIpolicy(amd1) = Mandatory
DS_MDV_BC#0(amd1) = 0.0 ms
ROC(amd3) = disable
SOS(amd3) = disable
===== amd5 =====
GINP_Field_length = 0
GVector_Field_length = 0this is after enabling g.inp in gui
Last edited:
That's strange, your line is shorter than mine (going by attenuation) but you must have some more crosstalk than me. It does seem possible that you'll get DLM intervention tomorrow, unless the spikes are only causing a few ES/SES at a time.
The fact upstream has also had intervention leads me to the possibility that DLM thought you re-synced too often, as I've only had it intervene on the downstream if the MTBE is exceeded. Either that or the behaviour of DLM has recently changed. I'm also amazed that G.INP wasn't applied first - unless DLM noted that you had no support and so didn't apply it (unlikely). The other possibility is that the changes to the DLM profiles (at exchange level?) haven't been done yet.
Associate
- Joined
- 11 Jul 2011
- Posts
- 178
- Location
- Aberdeen
This is exactly what I see with the DSL-AC68U. Last time I tried it when on Fastpath (and spectrum killed), I ended up with 7000+ CRC within 30 minutes or so, and I didn't want to risk being put back on Interleaved so I went back to the ECI modem. Not seeing the ES/SES is a major problem with the ASUS especially with the number of CRCs it can generate.
The ECI modem is rock solid for me, no DLM intervention and no disconnects.
So there's still something on some lines that's causing problems. It would be good if ASUS would go to BT and get their devices approved, at least that way we would know that the firmwares are based on settings which BT have allowed and will be compatible with both types of cabinet.
Ixel
Are you still introducing some level of interleaving to get yours to be stable, I've lost track of where you are up to.
Yes, I am - in order to get a green ILQ with DLM (assuming it doesn't look at FEC errors). With fastpath I'm able to hold a stable connection with a trickle of CRC errors pretty much identical to how the HG612 performs.
Associate
- Joined
- 7 Jul 2009
- Posts
- 510
- Location
- Bristol, UK
I've reverted to the HH5 again already.
Technically the line wasnt dropped according to the stats page, but my work laptop via a wired connection was dropping connections to my work Outlook and Lync servers every few minutes making working impossible. Its strange though as a ping from the modem itself to 8.8.8.8 (Google DNS) showed no packet loss. Since I've been back on the HH5 everything has been stable.
Technically the line wasnt dropped according to the stats page, but my work laptop via a wired connection was dropping connections to my work Outlook and Lync servers every few minutes making working impossible. Its strange though as a ping from the modem itself to 8.8.8.8 (Google DNS) showed no packet loss. Since I've been back on the HH5 everything has been stable.
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
Ok nothing ventured, nothing gained as they say. Managed to get myself a used DSL-AC68U for just shy of £85 which arrived this morning. It came with 2155 firmware so I guess its at the point the last user gave up on it.
Just downloaded the new release of 2160 to flash, fingers crossed. I've still got the previous 2160 just in case.
Just downloaded the new release of 2160 to flash, fingers crossed. I've still got the previous 2160 just in case.
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
The updated version of the 2160 firmware seems to favour my line. After 5hrs its recorded 0 CRC errors which is a marked improvement. My new found confidence in this router grows by the day.
You will get a FEC count and its numbers will vary once the line is interleaved. Thats partly what Interleaving does, controls errors or will give you FEC (Forward Error Correction). Entirely normal.
For anyone that has recently tried their Asus again and still has CRC issues even with spectrum killed It would be helpful to know which EXACT firmware they are using (i use EXACT in capitals as there are 2 different current versions of the latest firmware).
It would also be useful if they listed actual settings they are using (IE Annex mode, Is SRA on or off, etc etc etc something just minor could make a huge difference). Based on earlier posts that killing spectrum helps i can see no reason why it would not help other users. If it is not helping then there may be other settings which can help, which is why i suggest people state which options they have enabled/disabled and firmware versions in use.
Also an UPDATE
I have now managed to extract a version of the firmware for this device, i am not confident it is properly and fully extracted at the moment though or anywhere near ready to be recompiled and tested. I still have to play about getting it to recompile in a manner which will work for installation. Still aiming to try and get one to play with towards the end of the month, at that time ill dump things via TTL/serial and compare what ive done thus far. Id also if successful like to bring back the Mediatek config pages and also build the firmware with TC Console as well as regular Telnet options include for fuller functionality and easier tweaking.
Ill let you all know my progress, gonna be slow what with post xmas bills, family and other things.
If you want to replace the HH5 still then a TPlink W9980 May be a better choice as that uses the same basis of a chipset as the Homehub 5 and the ECI B-Focus Openreach modems.
Good to hear, is that the 2160 firmware with the suspected updated modem driver?
Last edited:
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
It is yes.
Edit: Almost at 8 hrs and still 0 CRC errors recorded. Even with a Broadcomm based router I would have seen some errors by now.
Last edited:
Just had a large jump. As I said, this line is rock solid on the HH5. I also have ferrites on the dsl and power cables coming into this box to try and reduce noise.
WOW mate you have so meny errors in such a short time.
here are my current status :
im ranking up around 100 or just over crc`a every 24h. with no ferries on anything. bog standard...... i probably have one of the best or most stable lines on fibre.
Last edited:
My daily CRC count is similar if I'm on fastpath under the similar conditions.
EDIT: Thought I read 1,000, not 100 CRC every 24 hours, Nevermind.
Still, mind if I ask what your settings are, as your upstream attentuation would indicate to me that you're reducing the transmit power offset?
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
I'm at 11hrs 40mins on the new 2160 firmware with just 1 CRC error on the US which is remarkable.