Anyone Using an Asus DSL-AC68U
- Thread starter Socrates470BC
- Start date
My test did the same, at the end of the test it showed 84000+ crc errors. I have to laugh, this morning I received an e-mail after telling him I've gone back on to the OR box, I get:
Regarding the interruptions concern, please go to Advanced Settings >
Administration > DSL Setting and configure with the following, see whether
your DSL line could be stabilized. Any other issue please feel free to let
us know. Thanks.
- Set "Stability Adjustment (VDSL)" to 10 dB.
Best regards,
Paul Lee
I won't say what really entered my head, but now the answer is to try something that doesn't work? O what again?
Why should I up my SNR and lose speed when I don't have to on the OR box?
I have increased my sync speeds (on OR box) from 35Mb to 43.9Mb Down and from 8Mb to 15Mb up since I've put 2 ferrite cores on and placed tinfoil over the adaptor. What do you know I also now only have very odd amounts of packet loss showing on thinkbroadbands broadband quality test. When running on the ASUS, It takes longer to re-sync (approx 45 mins) but the bugs are still there.
I think this is a poor adaptor and bad firmware hence why we are all seeing differences!
Last edited:
I got the same response from Lee after sending them several 24Hr diagnostic logs. It was at that point I returned it to PC world.
same here with adsl ... i am 2 days keeping an eye on it & the time running it seems has some effecting but no issues here, looks good the latest _2152
Last edited:
Had red packet loss at TBB same with firmware _2144, now with _2152 is ok
Take out any coil/foil (not the ferrites) because maybe can trap noise if is not grounding correctly
It wasn't until around 12dB SNRM (if I recall) that I managed to get some stability on fastpath, but as you can imagine the speeds were poor. If I put the device into interleaved (INP 3, delay 8ms, for example) it's stable and has few error seconds.
I've had my ferrites arrive this morning and have started to place four on the DSL-AC68U's power cable at various points, looping the cable once round them each time. I honestly don't believe it'll make a difference. I've also put tin foil carefully around the master socket. Using a shielded RJ11 cable as well (0.5m length). Double filtered the phone. I've also applied some ferrites to the phone's power cable, the switch power cable, and the other router's power cable.
I've had my ferrites arrive this morning and have started to place four on the DSL-AC68U's power cable at various points, looping the cable once round them each time. I honestly don't believe it'll make a difference. I've also put tin foil carefully around the master socket. Using a shielded RJ11 cable as well (0.5m length). Double filtered the phone. I've also applied some ferrites to the phone's power cable, the switch power cable, and the other router's power cable.
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
It does kind of slap you in the face, the fact you keep going round in circles and they don't seem to listen to what you tell them.
I got the feeling Paul Lee was just working from a script some days.
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
You need to attach the 'kitchen sink' as a ground point. hehehe
Good point on the grounding, I am now returning it to broadbandbuyer for a replacement, no argument from them it's past 3 months unfortunately. Let's see how many I go through lol
The power supply theory may be worth more investigation. I've put on ferrites on various cables today, including now currently three on the power cable for the DSL-AC68U (with the cable looped round the ferrite once before clipping shut). I'm currently on INP 1 with a delay of 4ms and I'm currently barely getting any error seconds, at best an average of 6 an hour. In the past when I've tested this at up to 80Mbps I've found myself getting a regular amount of CRC's even on a low INP and low delay configuration.
FEC's are still through the roof but Paul Lee says, to more or less summarise what he said, basically to ignore it as it's just errors being corrected (or FEC showing it's working) and won't effect performance (though I realise that bit obviously).
If this continues I will dare the test of fastpath again.
FEC's are still through the roof but Paul Lee says, to more or less summarise what he said, basically to ignore it as it's just errors being corrected (or FEC showing it's working) and won't effect performance (though I realise that bit obviously).
If this continues I will dare the test of fastpath again.
Associate
- Joined
- 11 Jul 2011
- Posts
- 178
- Location
- Aberdeen
I'm finding the 2152 firmware to be OK - admittedly still on interleaved downstream but no CRCs downstream / 2 upstream and in 7 hours connection time 111,000 FEC count downstream.
Maybe I'm not seeing any impact on the power supply as I have the router on a shelf at the opposite end to where the phone socket is. So possibly already minimising impact of REIN.
Perhaps I'll eventually get back onto fastpath downstream and will see how things compare then.
Maybe I'm not seeing any impact on the power supply as I have the router on a shelf at the opposite end to where the phone socket is. So possibly already minimising impact of REIN.
Perhaps I'll eventually get back onto fastpath downstream and will see how things compare then.
Although I've still had some CRC spikes, I haven't experienced a loss of sync yet. Previously I've lost sync within 2 hours of uptime.
So, perhaps the ferrites have made an improvement, but it still isn't that ideal (especially for those with an ISP that orders FTTC with the 'standard' DLM profile and not the 'speed' DLM profile).
I'll probably resync my connection back to INP 1 with a delay of 4ms later this morning in order to reduce the number of errors significantly.
Code:
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec: 0(209515574)
near-end path0 crc: 14674(2401)
near-end fec sec: 0(104688)
near-end err sec: 562(872)
near-end ses sec: 24(70)
near-end los sec: 0(0)
near-end ua sec: 22(339)
far-end path0 fec: 80(357417)
far-end path0 crc: 14(1379)
far-end fec sec: 15(6153)
far-end err sec: 13(1021)
far-end ses sec: 0(0)
far-end los sec: 0(451)
far-end ua sec: 0(20130)
outDiscards=70
inDiscards=5435
outBytes=1132835471
inBytes=4108752634
outPkts=23605068
inPkts=29712094
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.5 dB
AttenDown=10.4 dB
SNRMarginUp=12.5 dB
AttenUp=0.1 dB
DataRateDown=79999 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=0
FECUp=80
CRCDown=14674
CRCUp=14
HECDown=0
HECUp=0
ADSLUpTime= 7:27, 39 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.5 dbm
PowerUp=6.4 dbm
AttainUp=29290
AttainDown=97328
ShowtimeStart=19
TotalStart=173
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplusSo, perhaps the ferrites have made an improvement, but it still isn't that ideal (especially for those with an ISP that orders FTTC with the 'standard' DLM profile and not the 'speed' DLM profile).
I'll probably resync my connection back to INP 1 with a delay of 4ms later this morning in order to reduce the number of errors significantly.
Last edited:
I'm away to move house in the next month and would like to get the best out of my line. As fiber is more prone to issues, would you recommend fitting new faceplates and ferrites around the incomer cores? I have no idea on extensions etc yet so will want to pull in the finest cable going to ensure my connection is tip top.
My cab appears closer on the map than my current address but is saying to expect less speed. I guess it will be a suck it and see waiting game.
My cab appears closer on the map than my current address but is saying to expect less speed. I guess it will be a suck it and see waiting game.
I'm not sure. I've just added clip-on ferrites to the power cable of the DSL-AC68U, other switched mode power supplies in use near it (such as other router, cordless phone, switch) and finally on the phone cable going to the master socket. I would recommend making sure you have one of the VDSL2 intended SSFP's (MK1, MK2 or MK3, though personally I feel MK2 works best for me).
On another note, I'm back on INP 1 with a delay of 4ms and I think I'll stay to that unless ASUS improves that particular issue (thousands of CRC errors after a few hours of uptime on fastpath at an SNRM of around less than 12dB - based on my connection observations). I only lose a very minor amount of SNRM on the downstream and ping to bbc.co.uk goes from 8ms to 12ms. This is still perfectly acceptable for me even as an online gamer. I can still sync at around 80Mbps downstream as well.
Code:
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec: 4785559(214299893)
near-end path0 crc: 81(5517)
near-end fec sec: 4044(108731)
near-end err sec: 12(1754)
near-end ses sec: 1(72)
near-end los sec: 0(0)
near-end ua sec: 0(388)
far-end path0 fec: 23(357448)
far-end path0 crc: 3(1383)
far-end fec sec: 9(6165)
far-end err sec: 3(1025)
far-end ses sec: 0(0)
far-end los sec: 0(454)
far-end ua sec: 0(20174)
outDiscards=387
inDiscards=5675
outBytes=1929118678
inBytes=1589697978
outPkts=25431050
inPkts=31639754
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.4 dB
AttenDown=10.4 dB
SNRMarginUp=9.5 dB
AttenUp=0.3 dB
DataRateDown=79997 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=4785559
FECUp=23
CRCDown=81
CRCUp=3
HECDown=0
HECUp=0
ADSLUpTime= 1:19, 17 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.5 dbm
PowerUp=6.0 dbm
AttainUp=25739
AttainDown=109144
ShowtimeStart=19
TotalStart=193
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=384
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplusI've also reduced my tx power slightly because I don't need all that spare SNRM on the upstream (SNRM from 12dB~ now to 9dB~).
Perhaps ASUS should consider offering an option to change the INP and delay of the downstream (a bit like the Fritz!Box does, except I found that the setting didn't work on that device).
EDIT: Forgot speedtest.net result.
Last edited:
tandys had a good one but have not tested with the ac68u
note it can be tricky if is shielded because i am not sure if asus rj11 port is grounded (have not checked) or not ... if it isn't then it will not help
other than that' if any other model rj11 port is grounded should work good the outer is metal (near by the ends) for grounding
i don't know if i am allowed to post link
Best bet would be to pull CAT5e cable from the 2 krone connections on the VDSL faceplate. This gives you the cleanest possible path back from the master socket rather than using the inferior internal telephone wire that is normally used.
http://s672.photobucket.com/user/Ronskiman/library/Computer/xDSL%20extension%20wiring?sort=2&page=1
Last edited:
Thanks! That was what I thought on pulling through after we done a mates house with the same. Just wasn't sure if there was anything even better.
I used CAT5E on mine but was only about 5 m worth of cable. CAT6 is better but I am not sure if you would gain anything much if at all.