Anyone Using an Asus DSL-AC68U

[Ixel]

Firmware version 2158 without spectrum, original bitswap.

FEC has no longer kept its trend, so I won't bother with the setting my target SNRM to 9.0dB and will just leave it at the default ISP setting of 6.0dB when I next re-sync.

 

[sga1111]

Good point actually, another slight possibility is that the DSLAM has also had changes like mine recently has, though I believe mine happened during the daytime (when that random disconnect I recall happening). Failing that it might just be DLM making an adjustment.



I haven't tried with spectrum off just yet, though I will try that. I think 2155 worked better with a lower SNRM (initially anyway, errors/re-sync occurred after a while, where on the older firmware I'm using the errors appear instantly on 6dB SNRM fastpath). I wouldn't try setting 200Mbps max sync rate when vectoring is available as the ISP will likely see that - plus it's not the package speed limit that I'm paying for sadly.

I had a BT engineer out the other day to sort my line out, I can confirm that BT are installing vectoring cards (Engineer confirmed) so I think they will be rolling out vectoring in the very foreseeable future.
If I find anything else out I'll let you know.

 

[Ixel]

I had a BT engineer out the other day to sort my line out, I can confirm that BT are installing vectoring cards (Engineer confirmed) so I think they will be rolling out vectoring in the very foreseeable future.
If I find anything else out I'll let you know.

That's great news, hopefully they are installing vectoring into the ECI DSLAM's too. As I'm on ECI, perhaps what I saw wasn't a mistake or glitch then.

 

[danivtec]

That's great news, hopefully they are installing vectoring into the ECI DSLAM's too. As I'm on ECI, perhaps what I saw wasn't a mistake or glitch then.

Pretty sure I have read that ECI hardware installed by BT is vectoring capable.

If they are installing cards now then it can't be too far off a release.

 

[babis3g]

i find 2158 with spectrum pretty good with adsl line (dsl settings bit swap ADSL only - VDSL was disabled)
it did drop the snr but then it bring it back up near to the default (lower to 21 when was peak time Xmas eve as well everybody at home - up to 23 - default 25) ... plus at the time to many heavy electrical devices was in use (air condition - electric heater for hot water etc)

I have few crc errors 435 but as said was heavy evening (all what was missing for testing was a heavy rain) ... some broadcom modems will have as well around 300 crc errors depending the day ... so i think the bit swap change in this firmware is good for ADSL
Previous firmware will not bring up my snr (if lower)

I will keep this firmware to monitor for next day as well to make sure, when is off peak time again if snr still go more up ... & also if drop again peak time

Happy Holiday

PS
did not had that strange message for me at tc console

 

[Ixel]

i find 2158 with spectrum pretty good with adsl line (dsl settings bit swap ADSL only - VDSL was disabled)
it did drop the snr but then it bring it back up near to the default (lower to 21 when was peak time Xmas eve as well everybody at home - up to 23 - default 25) ... plus at the time to many heavy electrical devices was in use (air condition - electric heater for hot water etc)

I have few crc errors 435 but as said was heavy evening (all what was missing for testing was a heavy rain) ... some broadcom modems will have as well around 300 crc errors depending the day ... so i think the bit swap change in this firmware is good for ADSL
Previous firmware will not bring up my snr (if lower)

I will keep this firmware to monitor for next day as well to make sure, when is off peak time again if snr still go more up ... & also if drop again peak time

Happy Holiday

PS
did not had that strange message for me at tc console

Been working all day on 2158 with original bitswap and without spectrum. I only encountered that error message on the new bitswap. SNRM has been good too, is approximately 1dB higher than it was at showtime. I'll continue running this firmware for another 24 hours then try the new bitswap without spectrum, though I expect the problem to return when I do.

I think it's safe to now conclude that spectrum is the problem.

Merry Christmas everyone.

 

[babis3g]

They should publish some beta for other users having issue via their support or link .. more people testing better

Asus is aware by now & said will fine tune the spectrum & will not removed, this is the update i have by now

 

[sga1111]

That's great news, hopefully they are installing vectoring into the ECI DSLAM's too. As I'm on ECI, perhaps what I saw wasn't a mistake or glitch then.

I know for sure my cab has a vectoring card, so I think it can't be to far away

 

[Ixel]

I know for sure my cab has a vectoring card, so I think it can't be to far away

Is your cab a Huawei or ECI?

EDIT: Also I'm trying to reduce the FEC errors, I am still on the original bitswap for the moment. I'm seeing what effect reducing the AGC VREF (RX AGC Gain) to something like 200 will have (minimum is 394 via web UI at the moment).

 

[sga1111]

Is your cab a Huawei or ECI?

EDIT: Also I'm trying to reduce the FEC errors, I am still on the original bitswap for the moment. I'm seeing what effect reducing the AGC VREF (RX AGC Gain) to something like 200 will have (minimum is 394 via web UI at the moment).

It's a Huawei, they've been doing a fair bit of work in it. If I have another visit I'll ask a few more questions about ECI, see if I can get any info.

Merry Christmas

 

[Ixel]

It's a Huawei, they've been doing a fair bit of work in it. If I have another visit I'll ask a few more questions about ECI, see if I can get any info.

Merry Christmas

Ok thanks, you too. I can't imagine they'd forget about their ECI cabinets.

 

[babis3g]

ASUS DSL-AC68U Firmware version 3.0.0.4.376_2158 (This product supports both Annex A and Annex B)
1. Fix time zone related bug. Update time zone list.
2. ADSL WAN (ATM) QIS manual setting list updated
Add United Kingdom ISP, Aquiss
Add United Kingdom ISP, AOL
Add United Kingdom ISP, Vodafone
Add United Kingdom ISP, Utility Warehouse
Add United Kingdom ISP, Freeola
Add United Kingdom ISP, Eclipse
Add Germany ISP, Tele2
Add Germany ISP, swb
Add Germany ISP, Osnatel
Add Germany ISP, NetAachen
Add Australia ISP, Adam Internet
Add Australia ISP, Amnet
Add Australia ISP, MyNetFone
Add Australia ISP, ClubTelco
Add Australia ISP, Telstra Bigpond
Add Australia ISP, iTrinity
Add Italy ISP, Infostrada
Add Italy ISP, Alice
Add Italy ISP, Ehiweb
Add Turkey ISP, Vodafone
Add South Africa ISP, MTN Business
Add South Africa ISP, iSAT
Add South Africa ISP, Axxess
Add South Africa ISP, Cybersmart
Add South Africa ISP, Web Africa
Add South Africa ISP, Openweb
Add South Africa ISP, Vox Telecom
Add South Africa ISP, MWEB
Add New Zealand ISP, BigPipe
Add New Zealand ISP, Flip
Add New Zealand ISP, WXC
Add New Zealand ISP, Digital Island
Add Poland ISP, Netia
Add Poland ISP, Orange
Add Russia ISP, MTC - Максим
Add Russia ISP, Rostelecom
Add France ISP, OVH Télécom
Add France ISP, Magic Online
Add Greece ISP, TELLAS
Add Greece ISP, Wind Hellas
Add Spain ISP, Telefónica
Add Ireland ISP, Eircom
Add Algérie ISP, Algerie Telecom
Add Denmark ISP, Fullrate
Add Norway ISP, Nextgentel - Bredband
Add Jersey ISP, Newtel
Add Saudi Arabia ISP, Saudi Telecom Company - Jood
Add Luxembourg ISP, Post - LuxDSL
Add Morocco ISP, Maroc Telecom
Add San Marino ISP, San Marino Telecom
Add Guernsey ISP, Sure
Add Sweden ISP, Bredbandsbolaget
Add Netherlands ISP, XS4ALL
3. VDSL WAN (PTM) QIS manual setting list updated.
Add Australia ISP, TransACT
Add United Kingdom ISP, UTV Internet
Add United Kingdom ISP, Aquiss
Add Italy ISP, Fastweb
Add Italy ISP, Telecom Italia
Add Czech Republic ISP, Telefónica Czech Republic O2
Add Ireland ISP, Magnet Networks
Add Ireland ISP, Eircom
Add New Zealand ISP, Spark
Add New Zealand ISP, Turnstone
Add New Zealand ISP, 2Talk
Add Turkey ISP, TTNET
Add Turkey ISP, isNet
Add Greece ISP, OTE
Add Netherlands ISP, Telfort
Add Russia ISP, Ростелеком
Add Isle of Man ISP, Manx Telecom
Add France ISP, Orange
Add Germany ISP, o2 (Telekom VDSL Resale Anschluss)
Add Germany ISP, Deutsche Telekom (ohne Entertain)
Add Germany ISP, Deutsche Telekom (mit Entertain)
Add Germany ISP, EWE
Add Germany ISP, Freenet (über 1&1)
Add Germany ISP, GMX (über 1&1)
Add Germany ISP, M-net
Add Germany ISP, M-net (Telekom VDSL Resale Anschluss)
Add Germany ISP, Vodafone
Add Germany ISP, Vodafone (Telekom VDSL Resale Anschluss)
Add Germany ISP, swb (Telekom VDSL Resale Anschluss)
Add Germany ISP, Osnatel (Telekom VDSL Resale Anschluss)
Add Germany ISP, NetAachen
Add Germany ISP, willy.tel
Add Germany ISP, Easybell

 

[Ixel]

Presumably that contains the original bitswap still, as no mention included in changelog. I'll be trying the new bitswap again this evening. I appear to be getting more ES than usual at the moment, perhaps due to Christmas and possibly some lights somewhere causing interference here.

 

[babis3g]

see this traffic tonight, its not from end as i am not using much the internet

i still have the 2158 with spectrum still solid the snr
how ever are some HEC errors and up crc but i guess is normal some broadcom modems will have that for my line

 

[danivtec]

Ok thanks, you too. I can't imagine they'd forget about their ECI cabinets.

Pretty sure ECI cabinets are easily updatable for vectoring.

 

[Ixel]

Not entirely sure if it's related to possibly Christmas light interference, but I'm getting some bad errors at the moment. To eliminate the possibility of firmware I'm going to go back to 2155 official and manually kill spectrum later this evening. In the meantime I'm going to re-sync with INP 3, delay 8ms, to reduce the errors.

near-end path0 fec:     28043506(90683881)
near-end path0 crc:     13027(2598)
near-end fec sec:       18062(48792)
near-end err sec:       440(535)
near-end ses sec:       97(125)
near-end los sec:       0(0)
near-end ua  sec:       147(420)
far-end path0 fec:      2654(542125)
far-end path0 crc:      0(1983)
far-end fec sec:        50(9109)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(738)
far-end ua  sec:        0(32704)
outDiscards=365
inDiscards=2645
outBytes=3751624249
inBytes=3694806447
outPkts=12734437
inPkts=9185756
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.0 dB
AttenDown=10.4 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=77574 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=28043282
FECUp=2654
CRCDown=13027
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 6:08, 16 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.9 dbm
PowerUp=4.8 dbm
AttainUp=25394
AttainDown=99952

 

[Ixel]

Running the new bitswap firmware without spectrum (2158_1222) and the qdma error has returned after some hours of running TC Console (interactively, probably will happen if a 24 hour diagnostic was done too). I'll observe connection behaviour before I inform ASUS. I think I may have to wait until after Christmas, as I might be suffering some interference from Christmas lights at the moment. Only started around Christmas day and is requiring me to keep INP at 2 or higher in order to minimise the number of error seconds.

EDIT 27/12/2014 20:19 GMT:
So far around 7:30pm-8:00pm I seem to start suffering noise. Phone is fine, however the DSL connection goes crazy and eventually loses sync. Happened since Christmas day I believe so I imagine it's either related to Christmas lights or perhaps something someone unwrapped and plugged in since (I hope not, or I will be suffering this for a long time after Christmas). I believe other than the qdma error that the new bitswap would probably be fine. I've had to increase INP to 5 and delay to 16ms temporarily, will see if that keeps the connection stable.

 

[Ixel]

Another update.

Running 2158 with new bitswap and spectrum removed, I've observed that the downstream SNRM more or less remains the same as it was initially at showtime (unlike the old bitswap where it seems to gradually rise by around 1dB). For some reason I've not had the qdma error happen again overnight.

One other observation so far is that bumping my target SNRM up from 6.0dB to 9.0dB has made a significant difference in minimising the errors, especially for some point beyond 7:30pm-8:00pm when I seem to get that random problem as previously mentioned since Christmas day. I've always wondered if having a target SNRM of 6.0dB on VDSL2's downstream (particularly on non-vectored connections) was a good idea, I notice Australia seems to have 9.0dB or 12.0dB as the target SNRM.

I'm currently on INP 3 with a delay of 8ms. I will remain like this until DLM makes positive changes to my connection (as I'm currently way into the 'green' MTBE threshold - which is good). After DLM has made changes and restored my downstream profile then I'll gradually reduce the INP and delay and post further updates accordingly. RX AGC Gain is now set to 'High Performance' (550) as well.

EDIT:
I might consider going back to 2155 and see if I still get the interference mentioned.

EDIT 2:
Will be going back to 2155 nearer midnight tonight. I don't think I'm getting interference around 8pm, I think it's something in 2158 test firmwares. To be absolutely sure I will return to 2155 and kill the spectrum process manually. My error rate progressively gets worse after 12-14 hours of uptime, regardless of the time I synced at, hence why I don't think it's interference.

EDIT 3:
So far, over 18 hours of uptime on the original 2155 with spectrum killed and only 9 ES downstream. No indications of a error rate progressively increasing yet. Still getting the qdma error every so often so clearly can't be related to 2158 or the new bitswap, instead must be something else but that's fine.

Will stop posting further updates until there's some other activity here.

 

[cuke2u]

Good work, do you think asus will be using your findings in their next firmware release?

 

[Ixel]

Good work, do you think asus will be using your findings in their next firmware release?

I don't honestly know, I believe they are keeping track of this thread however as I was asked if Ixel was my forum name. I will send them a summary soon of what I've found when testing the different firmware versions.