Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: andy66 on October 08, 2014, 06:50:40 PM
-
As subject, is there anyone out there with an ASUS DSL-N66U who has a stable openreach VDSL2 connection with it?
I bought one when my (out of contract) homehub3 became faulty, and never got the VDSL stable.
The process of trying wrecked my DLM/profile (down to 47388 kbps, and it never held that for 24 hours).
I've now been using my old Huawei HG612 for long enough for my DLM/profile to recover. It has absolutely solid sync with download speed over 75Mbps and IP Profile of 77.42 Mbps / 20 Mbps. I'm using the DSL-N66U in "Ethernet WAN" configuration.
My impression is the DSL-N66U is completely bug ridden (both 1.0.7.3 and 1.0.7.7).
As the DSL-N66U is doing a useful job for me, I'm willing to give ASUS some time to get the f/w so the product works.
Eventually, however, if not fixed it'll have to be returned as a non-functioning product.
Hence my question, is there anyone out there with an ASUS DSL-N66U who has a stable openreach VDSL2 connection with it? (i.e. Are they all bad?)
If you have a stable connection, was there a magic combination of settings that made it work for you, and is it syncing at a decent speed?
-
I am going to do the horrible thing and not answer your question in the positive sense (sorry)
I had one, and frankly it didn't behave well at all
I had read the grief that others had trying to get a stable, reliable connection, however I assumed that as most seemed to be running Infinity 2 (or equivalent) link speeds, my Infinity 1 (40/10) might have more luck, as the slower the link speed the easier a job the modem would have maintaining sync.
Bad assumption.
It synced up ok , but then started dropping PPP sessions (LCP link down), and then after a few drops would then drop the actual vdsl2 link and cause a resync. I was lucky to get 30 mins uptime.
I tried everything I could in terms of tweaks, including the not-so neighbourly "Disable UPBO" and the uplink tx power reduction, and I couldn't make it better at all.
At one point I managed to get 3K+ CRC errors in the space of less than an hour, and I think this points to the root cause. The PPP session was dropping due to the keep-alives getting lost, and then so many errors occurred that the link was dropped.
There was also some serious strangeness with what the telnet grabbed stats were telling me, but that is another story.
Now, this points to a crap path to the cabinet, yet my Homehub5 has only dropped the link once in 2 weeks, and performs very well (modem wise). I obviously don't have access to any more line stats (i.e. CRC error count) using that device, but basically the link is as near 100% stable as you can get - it cannot be that bad else the HH5 would be having problems as well.
So, I gave up with the Asus. A real shame - it has a lot of potential ...
I have a Billion 8800NL on its way that will reveal more about the link condition, but basically I think the Asus vdsl2 driver is a bit unforgiving, very prone to errors and in my case was totally unreliable, even on a 40/10 connection :(
-
The DSL-AC68U suffers from the same problem.
Mines going back to the store tomorrow, sick of trying to get it stable after 8 days.
-
Thanks guys for sharing your experiences. I'd previously read quite a lot of reviews from unhappy users of this router, which is why I'd put "Mixed reviews" in the list of Combined VDSL2 Modem Routers (http://forum.kitz.co.uk/index.php?topic=14436.msg269710#msg269710). Ive now downgraded it to reflect the overwhelming fact that can no longer be ignored, that I dont think Ive seen anyone that is actually happy with its performance.
Lets hope that Asus can pull their finger out and push some firmware to resolve these issues.
-
I stuck with the Asus whilst they analysed some data I captured for them. Today under DSL SETTINGS I noticed G.INP 998.4 was enabled which I think is for Sky only currently. Since disabling its like having a different device so far.
-
The DSL-AC68U suffers from the same problem.
Mines going back to the store tomorrow, sick of trying to get it stable after 8 days.
I been try that last week - took it back to pcworld the day after! Because I am sick of this stupid webpage kept staying like this. I try resetting five times, try other pc computer, try on my laptop, try on wifi, try different browser and it still refused to let me in because there is no login & password on the website 192.168.1.1 just this screen below:
-
OP here.
After a few months of using HG612, and letting its stability return my profile/DLM to 80/20, I gave the DSL-N66U another go. This time with a new Mk3 faceplate (replacing the Mk1 with which the HG612 worked perfectly).
The DSL-N66U now appears stable!
Been a few months since I last tried so my line may have changed, but all I know that I've changed is the faceplate.
It stayed up 4.5 days with all default VDSL settings 'till it got confused and dropped the DSL as I was fighting the buggy parental controls sometime after this:
DSL Driver Version FwVer:5.4.11.25_A_TC3095 HwVer:T14.F7_0.0
DSL Link Status up
DSL Uptime 3 days 9 hours 20 minutes 50 seconds
DSL Modulation ITU G.993.2(VDSL2)
Annex Mode ANNEX_A
SNR Down 7.2 dB
SNR Up 15.3 dB
Line Attenuation Down 6.0 dB
Line Attenuation Up 3.8 dB
Data Rate Down 79999 kbps
Data Rate Up 19999 kbps
MAX Rate Down 87892 kbps
MAX Rate Up 23753 kbps
POWER Down -2.0 dbm
POWER Up -1.5 dbm
CRC Down 17348
CRC Up 486
My settings are now default except these two in Administration -> DSL Setting:
- Rx AGC GAIN Adjustment (VDSL) = stable and
- -3dB "Tx Power Control"
[Note these settings drastically reduce the reported SNR Up from 15dB to 7dB as they go some way to reducing the overall, and evening out the up and down CRC]
So it's now stable and I'm using it.
All is not perfect however - I await firmware updates to fix some of the bugs. e.g.
- 5GHz wifi throughput seemingly limited about 6Mb/s despite perfect MCS index. This started at f/w 1.0.7.7 - with 1.0.7.3 my 5GHz wifi throughput was limited by the WAN speed.
- Parental control not working properly.
- Samba share of USB drive only usable without accounts (open on LAN). DSL-N66U stuck with just one account - nothing I do in the GUI can delete it or add others (GUI claims to, but changes are not reflected in device configuration files or device behaviour).
-
is this line fast path or interleaved?
-
is this line fast path or interleaved?
I believe fast path, but I'm not certain.
There is nothing in the GUI interface to tell you.
# adslphxcmd info --state
adslphxcmd: ADSL driver and PHY status
Status Showtime
Channel: Fast, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps
but I don't entirely believe adslphxcmd output as some of it is randomly varies between calls and is clearly garbage.
ping looks quick enough (latency spikes are while streaming TV):
http://www.thinkbroadband.com/ping/share/609842661cf87803286faa92c1b39196-12-01-2015.html
If you're suggesting that the DSL-N66U can handle fast path but not interleaved - yes that could be the case. I hope not to find out.
-
You may want to make sure the spectrum process is killed via telnet.
killall -9 spectrum
I'm almost certain the same problem exists on the DSL-N66U as does the DSL-AC68U.
-
You may want to make sure the spectrum process is killed via telnet.
I'm almost certain the same problem exists on the DSL-N66U as does the DSL-AC68U.
Yes, I've been following the overclockers thread - your progress documented there is what inspired me to give the DSL-N66U another go. When I tried again, it worked on default settings. I don't have the luxury of being able to play too much - the link has to be reliable for (work) 1hr skypes. Random resyncs are not acceptable and I don't want to get into using "settings" (like the kill spectrum) that are not preserved through power cycles.
-
whats the url to the overclockers thread?
-
whats the url to the overclockers thread?
http://forums.overclockers.co.uk/showthread.php?t=18606945&page=35
-
http://forums.overclockers.co.uk/showthread.php?t=18606945&page=6
yeah same thread.
I think these devices could possibly end up been banned, the fact they can work with no UPBO on short lines is crazy LOL.
A guy on there whacked his US margin to over 20db by removing UPBO, I wonder how many long lines broke when he did that?
-
You may want to make sure the spectrum process is killed via telnet.
I'm almost certain the same problem exists on the DSL-N66U as does the DSL-AC68U.
Ixel,
OK, out of curiosity, I killed the spectrum process on my now stable connection to see if it made any difference to the slow and steady accumulation of CRC.
It did not. Not doubting your DSL-AC68U results, but the spectrum process does not appear to affect my DSL-N66U:
DSL Uptime 0 days 6 hours 1 minutes 20 seconds CRC Down 110 CRC Up 44 .43/min (2am-8am)
DSL Uptime 0 days 7 hours 29 minutes 58 seconds CRC Down 179 CRC Up 59
DSL Uptime 0 days 8 hours 0 minutes 15 seconds CRC Down 191 CRC Up 64
DSL Uptime 0 days 9 hours 49 minutes 10 seconds CRC Down 217 CRC Up 77 .5/min
DSL Uptime 0 days 17 hours 42 minutes 59 seconds CRC Down 499 CRC Up 160 .62/min
DSL Uptime 0 days 18 hours 41 minutes 37 seconds CRC Down 569 CRC Up 169 .66/min
DSL Uptime 0 days 22 hours 31 minutes 29 seconds CRC Down 842 CRC Up 207
DSL Uptime 0 days 23 hours 11 minutes 39 seconds CRC Down 916 CRC Up 211 .81/min
DSL Uptime 0 days 23 hours 34 minutes 43 seconds CRC Down 920 CRC Up 216
DSL Uptime 1 days 8 hours 5 minutes 22 seconds CRC Down 1044 CRC Up 287 .69/min
DSL Uptime 1 days 15 hours 0 minutes 17 seconds CRC Down 1177 CRC Up 357
DSL Uptime 1 days 16 hours 39 minutes 4 seconds CRC Down 10344 CRC Up 375 splurge
DSL Uptime 1 days 17 hours 16 minutes 27 seconds CRC Down 10358 CRC Up 385
DSL Uptime 1 days 18 hours 44 minutes 3 seconds CRC Down 10389 CRC Up 394
DSL Uptime 1 days 20 hours 15 minutes 16 seconds CRC Down 10419 CRC Up 403
DSL Uptime 1 days 22 hours 0 minutes 1 seconds CRC Down 10459 CRC Up 414
DSL Uptime 2 days 4 hours 57 minutes 1 seconds CRC Down 10563 CRC Up 460
DSL Uptime 2 days 7 hours 0 minutes 40 seconds CRC Down 10634 CRC Up 481
DSL Uptime 2 days 10 hours 10 minutes 36 seconds CRC Down 10708 CRC Up 511
DSL Uptime 2 days 12 hours 15 minutes 31 seconds CRC Down 10746 CRC Up 532 since splurge: .33/min
DSL Uptime 2 days 15 hours 27 minutes 40 seconds CRC Down 10803 CRC Up 557
DSL Uptime 2 days 17 hours 21 minutes 41 seconds CRC Down 10830 CRC Up 571
DSL Uptime 2 days 20 hours 32 minutes 30 seconds CRC Down 10987 CRC Up 601
DSL Uptime 3 days 5 hours 18 minutes 41 seconds CRC Down 11096 CRC Up 656
DSL Uptime 3 days 5 hours 41 minutes 37 seconds CRC Down 11122 CRC Up 664
DSL Uptime 3 days 8 hours 10 minutes 52 seconds CRC Down 11193 CRC Up 677 since splurge: .49/min
** Kill spectrum process here **
DSL Uptime 3 days 8 hours 12 minutes 56 seconds CRC Down 11193 CRC Up 677
DSL Uptime 3 days 8 hours 25 minutes 50 seconds CRC Down 11195 CRC Up 678
DSL Uptime 3 days 8 hours 28 minutes 3 seconds CRC Down 11196 CRC Up 680
DSL Uptime 3 days 11 hours 49 minutes 13 seconds CRC Down 11266 CRC Up 706 since kill spectrum: .47/min (looks like no significant difference)
DSL Uptime 3 days 13 hours 29 minutes 38 seconds CRC Down 11287 CRC Up 717 since kill spectrum: .42/min (no significant difference from earlier with spectrum)
-
The spectrum problem, at least on the DSL-AC68U, doesn't cause trickling CRC's like you've got. The spectrum problem caused spikes and eventual loss of sync unless the connection was interleaved to some degree. That might be why you've noticed no difference.
-
Its entirely possible that differing types of noise and noise correction can have different effects. Their are different types of noise and different types of error correction to handle each. For example TCM (Trellis) is effective for background noise yet useless for REIN/SHINE. RS Encoding is better at handling REIN but cant cope with SHINE. However RS carries a lot of overheads so isnt efficient unless you have that type of noise. (INP &) G.INP is far more efficient, but Im not sure if its any better at coping with SHINE or by how much. Its why in some cases you have to use all algorithms in tandem.
As for spectral, Im not sure entirely what that is all about and how it works - afaik its something to do with the equipment learning which tones are noisy and taking them out of use. The idea behind this is (same as why some dslams block ham tones or RF filters) by taking the tones completely out of use, then it stops noise spread to neighbouring tones and large noise bursts perhaps taking a line out completely.. or at least stabilising the line because it will be recording less CRCs E/Secs. Therefore by switching off spectrum Ive no idea why it should make things better.. in fact I didnt know that domestic routers had that capability. Perhaps ASUS are dabbling with it. Has anyone asked what 'spectrum' is actually doing.
Bitswap supposedly takes out particularly noisy tones anyhow until next resync, is that how it 'learns'? .. or have I completely misunderstood what ASUS are trying to do.
-
I maybe wrong but I was under the assumption it was just to provide the tone spectrum graphs in the GUI.
-
I maybe wrong but I was under the assumption it was just to provide the tone spectrum graphs in the GUI.
So was I. I'm presuming it's querying the modem too often for SNRM and bitloading - and so is causing instability while running.
-
Sorry to bring that post back...but it looks like Asus has released a few firmware releases lately and i was wondering how the modem/router is behaving with BT infinity?
It seems like it has a reasonable price and quite a few features.