Anyone Using an Asus DSL-AC68U
- Thread starter Socrates470BC
- Start date
The reason for the TP-Link W9980 is that it uses the same chipset as the ECI cabinets and Kitz review is showing a near identical sync speed as the supplied BT modems.
Can anyone remember the website that shows your cabinet manufacturer, Uplift figure, Likelihood of it going live etc etc. I remember using it in the past but can't find it now.
Can anyone remember the website that shows your cabinet manufacturer, Uplift figure, Likelihood of it going live etc etc. I remember using it in the past but can't find it now.
Ah ok. Thanks for clarifying.
Update 2:
I'm now testing this by forcing fastpath on the downstream. I've kept the sync rate at 49Mbps maximum for the moment, just INP is 0 and delay is 1ms (fastpath). SNRM is approximately 16dB with an attainable downstream rate of 95392.
---
Update 1:
Test concluded. FEC count is now rising every second again. Test failed?
---
Am now on the new firmware, an interesting observation so far is the SNR and bitloading graphs.
Previous firmware:
Newest test firmware (2143):
As you should see, the newest test firmware produces smoother graphs and makes use of tones nearer the end of the 17MHz, where the older version doesn't. Bear in mind for the above graphs I have UPBO disabled (yes I know it causes some crosstalk, yes I'll be disabling it, but at this point I'm trying anything to see if I can get reduce the FEC's to a count similar to that of the HG612).
Early days yet, all depends on if the FEC goes into the tens or hundreds of millions after 24-48 hours of uptime.
I'm now testing this by forcing fastpath on the downstream. I've kept the sync rate at 49Mbps maximum for the moment, just INP is 0 and delay is 1ms (fastpath). SNRM is approximately 16dB with an attainable downstream rate of 95392.
---
Update 1:
Test concluded. FEC count is now rising every second again. Test failed?
---
Am now on the new firmware, an interesting observation so far is the SNR and bitloading graphs.
Previous firmware:
Newest test firmware (2143):
As you should see, the newest test firmware produces smoother graphs and makes use of tones nearer the end of the 17MHz, where the older version doesn't. Bear in mind for the above graphs I have UPBO disabled (yes I know it causes some crosstalk, yes I'll be disabling it, but at this point I'm trying anything to see if I can get reduce the FEC's to a count similar to that of the HG612).
Early days yet, all depends on if the FEC goes into the tens or hundreds of millions after 24-48 hours of uptime.
Code:
near-end path0 fec: 2255(2255)
snear-end path0 crc: 0(0)
near-end fec sec: 35(35)
=near-end err sec: 0(0)
near-end ses sec: 0(0)
near-end los sec: 0(0)
near-end ua sec: 0(0)
far-end path0 fec: 0(129580)
far-end path0 crc: 0(1120)
far-end fec sec: 0(3925)
far-end err sec: 0(969)
far-end ses sec: 0(0)
far-end los sec: 0(233)
far-end ua sec: 0(12793)
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.2 dB
AttenDown=10.5 dB
SNRMarginUp=12.2 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=2255
FECUp=0
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=11 min, 52 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.7 dbm
PowerUp=8.8 dbm
AttainUp=32919
AttainDown=110312
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Last edited:
23h+ test after 2 days of interleaved and dropped down to 69down20up after messing about with TC console my connection is back to normal
and interleaved returned to fastpath with 80down/20up maxed....downloaded about 80gb in 1 hour 45 minutes
and the errors are very low.
23h+ test after 2 days of interleaved and dropped down to 69down20up after messing about with TC console my connection is back to normal
downloaded about 80gb in 1 hour 45 minutes
and the errors are very low.
Which version of the ASUS firmware? And I presume you mean you disabled interleaving through TC or do you mean you forced interleaving for the 23h+ test - I'm confused?
nah mate i just waited for DSLM to repair the line back to normal lol
and im still on the previous beta firmware not the latest one above im waiting for more information on the latest one before i jump
need someone to do comparison tests between the new beta above and the previous beta to see if its worth it
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
23h+ test after 2 days of interleaved and dropped down to 69down20up after messing about with TC console my connection is back to normal
downloaded about 80gb in 1 hour 45 minutes
and the errors are very low.
Are you sure you're on fastpath, Asus said they were looking into reports it wasn't reporting correctly. People were still interleaved despite it saying fastpath.
As of 6pm tonight I'm no longer in possession of a DSL-AC68U, PC World took it back after 6 weeks without a quibble as they are being returned almost as quick as they left the store. In fact from looking at the stores display tonight they seem to have removed the item from sale.
mate im sure im back on fast path, with interleaved forced on i get pings in the region of low 30s and in the usa around 40s-50s
with fast path im 13ping/16ping in the uk on various servers and 28 to low 30s in the usa.
yeah im sure fastpath is enabled.
Well, conclusion from my testing is that this test firmware hasn't helped. The underlying problem still exists. In order to keep a stable connection I must remain on interleaving. If I want to go on fastpath I must maintain at least an SNRM of 15dB or higher on the downstream in order to maintain a stable connection with some error seconds. All problems are via the downstream, the upstream is fine whether it's fastpath or not.
The only reasons I'm sticking to this device is because it allows me to override the speed banding, meaning I'm now able to sync at 75Mbps~ with interleaving rather than DLM's speed banding of 49Mbps with interleaving. If it wasn't for that then I would be complaining to broadbandbuyer stating that this device is badly designed (not fit for purpose) and that I would like a refund applied as a credit on the account (as I bought it used, grade B). I'm hoping eventually ASUS will hit on the problem and fix it, but assuming they are making changes in each version, they are still continuing on releasing various beta/test firmwares it seems.
Also I believe they fixed path mode mis-reporting in the test firmware as it's saying interleaved here.
The only reasons I'm sticking to this device is because it allows me to override the speed banding, meaning I'm now able to sync at 75Mbps~ with interleaving rather than DLM's speed banding of 49Mbps with interleaving. If it wasn't for that then I would be complaining to broadbandbuyer stating that this device is badly designed (not fit for purpose) and that I would like a refund applied as a credit on the account (as I bought it used, grade B). I'm hoping eventually ASUS will hit on the problem and fix it, but assuming they are making changes in each version, they are still continuing on releasing various beta/test firmwares it seems.
Also I believe they fixed path mode mis-reporting in the test firmware as it's saying interleaved here.
Tbh if this is even semi accurate that just goes to show how much of a bad state this router is in.
I for one think it is time to get some sort of answer out of asus or at the very least ocuk and get a solid we will have this fixed by xx/xx/xxxx date just like samsung did recently with there ssd's afterall they did sell there product as fully working and had 5 star gold/diamond/platinum amazing reviews to back it up (i really am starting to think they didnt test this router for very long or it was never tested in the uk).
Soldato
I'm sort of happy with mine, but OK could give some more support and put pressure upon Asus to sort it out, or come on this forum and talk to us..
If the ASUS is mis-reporting, that might explain why it's currently showing me as being on fastpath even though my pings and traceroutes are still up at 30ms.
I've been running the latest beta firmware (1.0.1.9) since last weekend and so far have not had any disconnections (just over 5 days). I did a factory reset after upgrading the firmware and have left all the settings at default.
Unfortunately my speed is still dreadful since DLM hasn't deemed my connection worthy of a bump back up to the good old days of BT OR modem. Still at 22M/9M vs 37M/6.5M with BT OR.
Similarly puzzled by all the posative reviews, I finally got round to posting a negareview on broadbandbuyer, although they are still listing it as a 4star rating (apparently the average of 1 + 5 = 4 WTF?). Hopefully they won't give too much grief if I end up having to return it.
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
You need to keep a close eye on the FEC errors via telnet. Too many FEC errors and I doubt you'll ever get back to Fastpath.
Everytime I connected the ASUS I would be hit by DLM restrictions within 48hrs even with relatively low CRC/ES errors, I'm convinced DSLAMS take FEC errors in to account.
I'm now running a Billion 8800nl and over 24hrs my FEC rate DS was approx. 192,000. Same period much lighter use on the ASUS was generating close to 100 million errors.
Last edited:
I've not tried telnet-ing into the ASUS. I know I need to enable it in the router and get a telnet client running on my pc, but are there any special commands I need to get the FEC error data out?
I'm still playing around with mine, at the moment I'm trying various things such as changes to 'agc_vref' beyond the range on the GUI. I've reduced agc_vref to 0. I'll post results later today and keep everyone updated. When I set agc_vref to some higher number than usual, I get much more errors, so I figured I'd try 0 (which I imagine either stops boosting it or disables it. Rx AGC gain on the GUI when set to disabled appears to just make the agc_vref 440 (which is still gaining as I see it?). Maybe this is causing all of our errors on VDSL2?
Last edited:
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
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
Which ones should I actually be concerned about?
The key parameters are the ones concerned with physical layer errors –
Errored Seconds
Code Violations
FECs