Anyone Using an Asus DSL-AC68U

Ixel · 19 Dec 2014 at 14:10

chriscatt said:
No I am ok at the moment on the latest, 2155, firmware. I believe my interleaved download was due to the restarts I had right at the begining of owning this product. At the moment its been up for 9 days and I'm hoping that by the time I get back home after xmas I'll be running fastpath on my downloads again....

Ah ok, fair enough. Hopefully when fastpath is back, if it does come back, it will work fine for yours.

I've just noticed another observation on mine, not sure whether it's something I haven't noticed lately, the firmware, or whether BT are in the process of getting DSLAM's upgraded for a potential rollout next year, but I've compared my adsl diag output and noticed some differences, particularly to vectoring, SOS, and G.INP.

Below are some snippets...

Version 2072:

Code:

TX_SOS_enable  (amd3) = DISABLED
RX_SOS_enable  (amd3) = ENABLED

 rx_sos_tone_set_num = 3 TOTAL_TONE_NUM(DsNsc) = 2856
start_idx[0]=  33  end_idx[0]= 857  period[0]= 825  period_sum[0]= 825
start_idx[1]=1218  end_idx[1]=1959  period[1]= 742  period_sum[1]=1567
start_idx[2]=2795  end_idx[2]=4083  period[2]=1289  period_sum[2]=2856

--

RA-DSNRMds(amd1) = 0.0 dB
RA-DTIMEds(amd1) = 15360 sec
RA-USNRMds(amd1) = 0.1 dB
RA-UTIMEds(amd1) = 13826 sec

flexible_OH_frame_type2(amd3) = N
DS SOS MULTISTEP ACTIVATION(amd3) = DS All tones
US SOS MULTISTEP ACTIVATION(amd3) = US All tones
Mini Net Data Rate(DS)(Bearer Channel 0)(amd3) = 65792 kbit/s
Mini Net Data Rate(DS)(Bearer Channel 1)(amd3) = 128 kbit/s
DS SOS TIME(amd3) = 1472 ms
DS SOS-NTONES(amd3) = 237%
DS SOS-CRC(amd3) = 0. 0
DS MAX-SOS(amd3) = 16
DS SNRMOFFSET-ROC(amd3) = 179.2
DS INPMIN-ROC(amd3) = 0
===== amd5 =====
GINP_Field_length               = 16
vtuo_us_support_retransmission  = 1
vtuo_tx_dtu_option              = 0x      c4
vtuo_tx_hrt_delay_symb          = 0 Symbol
vtuo_tx_hrt_delay_dtu           = 0 DTU
vtuo_rx_hrt_delay_symb          = 0 Symbol
vtuo_rx_hrt_delay_dtu           = 0 DTU
DS (1/S)max                     = 8
US (1/S)max                     = 4
DS D1 value support     = 0x0
GVector_Field_length            = 48

Version 2155:

Code:

TX_SOS_enable  (amd3) = DISABLED
RX_SOS_enable  (amd3) = DISABLED

--

RA-DSNRMds(amd1) = 0.0 dB
RA-DTIMEds(amd1) = 0 sec
RA-USNRMds(amd1) = 0.0 dB
RA-UTIMEds(amd1) = 0 sec

flexible_OH_frame_type2(amd3) = N
DS SOS MULTISTEP ACTIVATION(amd3) = DS All tones
US SOS MULTISTEP ACTIVATION(amd3) = US All tones
Mini Net Data Rate(DS)(Bearer Channel 0)(amd3) = 0 kbit/s
Mini Net Data Rate(DS)(Bearer Channel 1)(amd3) = 0 kbit/s
DS SOS triggering criteria(amd3) = N
DS SOS-NTONES used in the decision criteria(amd3) = N
DS SOS-CRC(amd3) = 0. 0
No limit of DS MAX-SOS(amd3)
DS SNRMOFFSET-ROC(amd3) = 0.0
DS INPMIN-ROC(amd3) = 0
===== amd5 =====
GINP_Field_length               = 0
GVector_Field_length            = 0

Ixel · 19 Dec 2014 at 17:56

Just an update to say that it looks like my cabinet has been upgraded/modified, perhaps relating to the vectoring trial. A rollout might be underway/in preparation, as SOS is definitely enabled on mine for some reason, along with G.INP and G.VECTOR reporting different values. I also noticed that adsl diag is reporting something I've never seen before previously, what looks to be tones and noise which perhaps is related to vectoring's operation.

Code:

% band_idx:BAND_ALL
% rx_power_cal_num = 2856
% pilot tone :   212
% INDEX  NOISE_PWR       SIGNAL_PWR      IDEAL_SNR   SNR
  33         2109        54122       52       44
  34         2184        60503       53       46
  35         1918        67153       53       46
  36         2319        74121       54       46
  37         1985        81633       54       47
  38         2160        89665       55       48
  39         1788        97571       55       47
  40         1928       106130       55       48
  41         2589       115179       55       49
  42         2001       124426       56       48
  43         1992       131310       56       48
  44         2530       140909       56       50
  45         2064       147594       56       50
  46         2265       154173       56       50
  47         2694       164392       57       51
  48         2535       170887       57       51
  49         2424       177187       57       51
  50         2683       188004       57       51
  51         2627       194422       57       51
  52         2644       200830       58       49

Current stats look fine (FEC that is), and SNRM and bitloading graph look fine at the moment as well:

Code:

near-end path0 fec:     16638(16638)
near-end path0 crc:     0(0)
near-end fec sec:       202(202)
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:      436(467790)
far-end path0 crc:      0(1929)
far-end fec sec:        12(8020)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(648)
far-end ua  sec:        0(28938)
outDiscards=91
inDiscards=7
outBytes=447344968
inBytes=249528261
outPkts=1015900
inPkts=920261
fwVer= FwVer:5.5.1.124_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=13.1 dB
AttenDown=10.2 dB
SNRMarginUp=9.3 dB
AttenUp=0.1 dB
DataRateDown=42125 kbps
DataRateUp=20000 kbps
WanListMode=0
FECDown=16638
FECUp=436
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 1:51, 44 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.1 dbm
PowerUp=6.2 dbm
AttainUp=28579
AttainDown=96220
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1819
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

I'm unsure how to exactly verify if vectoring is enabled or if something has really changed in the cabinet recently. I suppose upgrading the firmware back to version 2155 would verify it as I could compare whether the adsl diag output also includes SOS and other changes as mentioned above. Alternatively I could connect the HG612 and see what that might say.

babis3g · 19 Dec 2014 at 18:10

I also have an update and Very possible related to the issue

That is why i like to see stats with the tc console or nay other tool and don't use the feedback where all are happening in the background

Was capturing the log for about 5 hrs ... was advised to turn off spectrum
About 15 min before the end of the 5 hrs ... i enabled the spectrum to see what will happen
Once enabled the spectrum was really fine as the start up (see screenshot upper posts)
The snr for all that time was 25 db stable according to the dsl log in the asus menu
Everything same as the broadcom modems (bit swap, snr etc)

Suddenly when enabled the spectrum it started to mess up
the tones started broke, few crc errors appeared and the snr dropped to from 25 db to 22 and was floating ... little more noise or from a bad weather could drop it more ( i ve seen it before)

I am sure is the spectrum how is build ... when is disable it seems the connection is solid

I am sure is related for causing somewhere the random errors/issues and for vdsl

EDIT

Unless the INI file was specially designed for my line because once i enabled the spectrum the tc console stopped working ... so if was in a special profile and stopped as well? together with the tc console?
Can the INI they have send me set special profile for my line?

Ixel · 19 Dec 2014 at 18:14

babis3g said:
I also have an update and Very possible related to the issue

That is why i like to see stats with the tc console or nay other tool and don't use the feedback where all are happening in the background

Was capturing the log for about 5 hrs ... was advised to turn off spectrum
About 15 min before the end of the 5 hrs ... i enabled the spectrum to see what will happen
Once enabled the spectrum was really fine as the start up (see screenshot upper posts)
The snr for all that time was 25 db stable according to the dsl log in the asus menu
Everything same as the broadcom modems (bit swap, snr etc)

Suddenly when enabled the spectrum it started to mess up
the tones started broke, few crc errors appeared and the snr dropped to from 25 db to 22 and was floating ... little more noise or from a bad weather could drop it more ( i ve seen it before)

I am sure is the spectrum how is build ... when is disable it seems the connection is solid

I am sure is related for causing somewhere the random errors/issues and for vdsl

Very interesting. I'll try disabling spectrum tonight (reboot and don't touch it basically) and see what fastpath yields (or at the very least, light level of interleaving). With SOS apparently being enabled I'm not sure how this will effect my ability to properly test this still. That in itself is strange, the firmware shouldn't randomly enable/change it so I imagine it must be a DSLAM modification recently (as vectoring might be rolling out here next year).

babis3g · 19 Dec 2014 at 18:19

EDIT

Unless the INI file was specially designed for my line because once i enabled the spectrum the tc console stopped working ... so if was in a special profile and stopped as well? together with the tc console?
Can the INI they have send me set special profile for my line?

Ixel · 19 Dec 2014 at 18:20

babis3g said:
EDIT

Unless the INI file was specially designed for my line because once i enabled the spectrum the tc console stopped working ... so if was in a special profile and stopped as well? together with the tc console?
Can the INI they have send me set special profile for my line?

Possibly, but without seeing the INI I can't tell you. I doubt ASUS would send me it if I requested it, so unless you can send me it through 'trust', that's the only way I can check.

babis3g · 19 Dec 2014 at 18:48

got anything? i am not sure how this trust works, thanks

Ixel · 19 Dec 2014 at 19:12

babis3g said:
got anything? i am not sure how this trust works, thanks

Yes, I got it. I've looked it and it doesn't do anything that would alter your connection settings, only print out the current settings and statistics (other than restarting the connection).

babis3g · 19 Dec 2014 at 19:24

i have reboot the modem by now trying to capture again (adsl) but it will not when i have spectrum on

Now i have disable the spectrum but the snr falling ... it may be because here is very peak time

I will try it again later one more to capture

babis3g · 19 Dec 2014 at 21:52

I run it one more time & everything is normal now, no crc errors or drop of snr (enabled later the spectrum like early) & was peak time now ... maybe the reboot ... i dont know

Ixel · 19 Dec 2014 at 21:58

Hmm, I see.

Well, here's my statistics so far for version 2072:

Code:

near-end path0 fec:     85427(85427)
near-end path0 crc:     0(0)
near-end fec sec:       557(557)
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:      1350(468704)
far-end path0 crc:      0(1929)
far-end fec sec:        24(8032)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(648)
far-end ua  sec:        0(28938)
outDiscards=306
inDiscards=37
outBytes=1734294692
inBytes=2723467249
outPkts=5188144
inPkts=5447960
fwVer= FwVer:5.5.1.124_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=13.2 dB
AttenDown=10.2 dB
SNRMarginUp=9.0 dB
AttenUp=0.1 dB
DataRateDown=42125 kbps
DataRateUp=20000 kbps
WanListMode=0
FECDown=85427
FECUp=1350
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 5:57, 31 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.1 dbm
PowerUp=6.2 dbm
AttainUp=28241
AttainDown=95864
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1819
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

Will try fastpath later this evening, or possibly reduce INP at the very least. I also want to possibly try 2155 again at some point to see if the SOS and other stuff I mentioned above also appears there, but I really do suspect that the DSLAM here has been modified in preparation for the vectoring rollout. Someone internal speculated (based on limited information) that there might be a rollout in February, so looks like that might be the case.

No noticeable interference on the graphs at the moment. Bitswapping seems to be working as intended.

EDIT 1:
Appears the DSLAM has been modified, most likely in preparation for the vectoring rollout. Version 2155 is also reporting this now.

cuke2u · 20 Dec 2014 at 09:45

WAN went down at exactly 02:00am this morning :-(

so I am going to reconnect the OR modem, write to asus and give them a blast that their product is not fit for its purpose and their support of it is appalling.

Ixel · 20 Dec 2014 at 10:20

chriscatt said:
WAN went down at exactly 02:00am this morning so I am going to reconnect the OR modem, write to asus and give them a blast that their product is not fit for its purpose and their support of it is appalling.

I'm tempted to buy the Fritzbox 7490 and try and sell my RT-N66U on the famous auction website (will wait until after new year though as people spending on Christmas and such), then have the RT-N66U replaced by the DSL-AC68U with the internal modem unused/disabled.

So far it looks like the newer firmware did have improved bitswapping, but obviously something else is still wrong. I'll be upgrading back to 2155 later today most likely, although the underlying problem still exists and requires me to maintain a reasonably high SNRM on the downstream in order to maintain a fairly stable connection.

babis3g · 20 Dec 2014 at 11:10

Ixel said:
EDIT 1:
Appears the DSLAM has been modified, most likely in preparation for the vectoring rollout. Version 2155 is also reporting this now.

set the dsl ac68u to 200Mbps when vectoring will be available

Have you tried with the spectrum turned off? i think is more stable ... but with this device i can be wrong again

Evil Shubunkin · 20 Dec 2014 at 11:29

chriscatt said:
WAN went down at exactly 02:00am this morning so I am going to reconnect the OR modem, write to asus and give them a blast that their product is not fit for its purpose and their support of it is appalling.

That's not necessarily down to the ASUS - around that time could be DLM or maintenance on the DSLAM. If you've not swapped over yet, worth checking what your interleaving is now as DLM intervention would most likely have changed that.

Ixel · 20 Dec 2014 at 11:30

Evil Shubunkin said:
That's not necessarily down to the ASUS - around that time could be DLM or maintenance on the DSLAM. If you've not swapped over yet, worth checking what your interleaving is now as DLM intervention would most likely have changed that.

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.

babis3g said:
set the dsl ac68u to 200Mbps when vectoring will be available

Have you tried with the spectrum turned off? i think is more stable ... but with this device i can be wrong again

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.

cuke2u · 20 Dec 2014 at 13:33

Points taken, I will check my pings later...

cuke2u · 20 Dec 2014 at 15:39

Ping seems to have gone up to 23ms now :-(

however I think my download speed is up http://www.speedtest.net/my-result/3999462698

Ixel · 20 Dec 2014 at 16:54

babis3g said:
set the dsl ac68u to 200Mbps when vectoring will be available

Have you tried with the spectrum turned off? i think is more stable ... but with this device i can be wrong again

So far your suggestion regarding not using the spectrum monitor seems to be oddly showing an improvement here. I will give it some more hours before I can say for sure if it really is or if this is just another potential false positive.

babis3g · 20 Dec 2014 at 22:08

Ixel said:
So far your suggestion regarding not using the spectrum monitor seems to be oddly showing an improvement here. I will give it some more hours before I can say for sure if it really is or if this is just another potential false positive.

ok thanks

, let me know when you ready if is better or in general is more stable your line with spectrum disable