Anyone Using an Asus DSL-AC68U

[Ixel]

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

near-end path0 fec:     499046(550348)
near-end path0 crc:     6(6)
near-end fec sec:       2043(2614)
near-end err sec:       4(4)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(65)
far-end path0 fec:      2130(473841)
far-end path0 crc:      0(1929)
far-end fec sec:        38(8140)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(664)
far-end ua  sec:        0(29360)
outDiscards=287
inDiscards=49
outBytes=3002713972
inBytes=2918750232
outPkts=8951262
inPkts=10238475
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=13.3 dB
AttenDown=10.3 dB
SNRMarginUp=9.3 dB
AttenUp=0.1 dB
DataRateDown=42119 kbps
DataRateUp=20000 kbps
WanListMode=0
FECDown=499046
FECUp=2130
CRCDown=6
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 7:34, 29 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.2 dbm
PowerUp=6.1 dbm
AttainUp=28739
AttainDown=105920
ShowtimeStart=19
TotalStart=56
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=577
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

This is with the downstream currently configured as:

*** RX BEARER[0] Capabilities ***
NET_MIN[0]        =    16 (x8 kbps)
NET_MAX[0]        =  5265 (x8 kbps)
MAX_INTL_DELAY[0] =     3 (ms)
INP_MIN[0]        =     0 (DMT symbol)

Target SNRM is 6.0dB (as set on the DSLAM)

I'll increase the maximum sync rate to 6125 (49,000 Kbps / 49 Mbps) later tonight and assess how that does. FEC isn't rapidly going upwards at the moment. I can't verify if there's significant interference on the bitloading/SNRM graphs as I'm avoiding the spectrum monitor page.

EDIT: Just noticed the 'spectrum' process running, so have issued a 'killall -9 spectrum' on telnet just to be safe. I wonder if it auto starts.

 

[babis3g]

EDIT: Just noticed the 'spectrum' process running, so have issued a 'killall -9 spectrum' on telnet just to be safe. I wonder if it auto starts.[/QUOTE]

Nice finding, 
Once i use it via telnet take a look this
Note i have not reboot the modem just disabled spectrum via telnet while the modem was up & running normal

see the white pic with bit swaps tones
[URL="http://forums.overclockers.co.uk/showpost.php?p=27364912&postcount=847"]http://forums.overclockers.co.uk/showpost.php?p=27364912&postcount=847[/URL]

after disabled spectrum bit swaps are almost all equal
I know routerstats is not an accurate tool but the indication can not be so wrong
I also not sure if this responsible for sudden increased fec errors but something is going on with spectrum

[URL=http://s1167.photobucket.com/user/babis3g/media/bitswapssamelevel_zps786f8586.png.html][IMG]http://i1167.photobucket.com/albums/q631/babis3g/bitswapssamelevel_zps786f8586.png[/IMG][/URL]

I will test again tomorrow when will reboot the modem & disable spectum from the begin

EDIT

Sadly i can not see either the spectrum or an other similar spectrum how reacts but i have the feeling it must respond more better

 

[Ixel]

Nice finding,
Once i use it via telnet take a look this
Note i have not reboot the modem just disabled spectrum via telnet while the modem was up & running normal

see the white pic with bit swaps tones
http://forums.overclockers.co.uk/showpost.php?p=27364912&postcount=847

after disabled spectrum bit swaps are almost all equal
I know routerstats is not an accurate tool but the indication can not be so wrong
I also not sure if this responsible for sudden increased fec errors but something is going on with spectrum



I will test again tomorrow when will reboot the modem & disable spectum from the begin

Hmm, how are you measuring bitswapping without spectrum monitor running?

 

[babis3g]

with router stats but the spectrum named bit & snr tone not works properly

but i will make a debug (they have send me new ini file - the one i sawed you) with tc console now to send the log with spectrum disabled

 

[babis3g]

after started tc console the dsl part disconnected and connected again
the monitor will show again spikes tones with different values so i used again killall -9 spectrum and now once again all tones are equal for second time

tc console is debagging right now so if is any change i hope tc console will capture it & see by monday what asus will say

 

[geneva78]

Wow both Ixel and babis should have worked in Asus instead of those engineers.
Great findings.

 

[Ixel]

after started tc console the dsl part disconnected and connected again
the monitor will show again spikes tones with different values so i used again killall -9 spectrum and now once again all tones are equal for second time

tc console is debagging right now so if is any change i hope tc console will capture it & see by monday what asus will say

I think you're on to something at the moment. I've once again tested fastpath at 49Mbps and had no CRC spikes and just the small trickle of CRC errors that I would see on my HG612. Unfortunately the FEC did become out of control when I tested interleaving at 3ms delay and 0 INP for a short duration, however the CRC errors were virtually non-existent. For the purpose of these tests I'm going to ignore the FEC value entirely, just observe the CRC errors and error seconds/severe error seconds.

near-end path0 fec:     0(13687081)
near-end path0 crc:     67(74)
near-end fec sec:       0(7775)
near-end err sec:       57(62)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(129)
far-end path0 fec:      2617(477306)
far-end path0 crc:      0(1929)
far-end fec sec:        17(8174)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(670)
far-end ua  sec:        0(29420)
outDiscards=43
inDiscards=68
outBytes=166548182
inBytes=1092928617
outPkts=11920956
inPkts=13401334
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=15.0 dB
AttenDown=10.4 dB
SNRMarginUp=9.3 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=0
FECUp=2617
CRCDown=67
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 3:37, 58 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.9 dbm
PowerUp=6.0 dbm
AttainUp=28785
AttainDown=91144
ShowtimeStart=19
TotalStart=93
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

I am now testing 54Mbps on INP 0 with a delay of 3ms (virtually no interleaving basically, almost fastpath). If that remains stable for the next 8-12 hours then I will bump the speed up to 60Mbps and see how that copes on the same INP and delay parameters. Spectrum is killed here at the moment.

If spectrum is responsible for causing the instability, then as a hypothesis I believe it might be probing the modem chipset too much, causing unreliable or delayed action in responding to appropriate tasks such as bitswapping. This might also be why I notice the graphs sometimes go wierd for one or two refresh cycles occasionally.

Wow both Ixel and babis should have worked in Asus instead of those engineers.
Great findings.

Thanks, hopefully we're on to something.

 

[Ixel]

Just another update after a few hours. FEC out of control as expected, but CRC's are neglible on the downstream despite the very light level of interleaving I've currently applied at the moment (almost fastpath). In the past I don't recall being able to apply such a low level of interleaving to this sync rate/SNRM.

DSL Settings

Firmware Version 2155

DS bearer channel 0 configuration
Min_net_data_rate =      128 kbit/s
Max_net_data_rate =      54000 kbit/s
Max_interleaving_delay = 3 ms
INP_min =                0 symbols

near-end path0 fec:     6140400(19875159)
near-end path0 crc:     6(82)
near-end fec sec:       10313(18138)
near-end err sec:       4(67)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(193)
far-end path0 fec:      471(477935)
far-end path0 crc:      0(1929)
far-end fec sec:        9(8188)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(676)
far-end ua  sec:        0(29479)
outDiscards=67
inDiscards=75
outBytes=876715439
inBytes=2412468665
outPkts=13642178
inPkts=15170414
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.8 dB
AttenDown=10.2 dB
SNRMarginUp=9.3 dB
AttenUp=0.1 dB
DataRateDown=53999 kbps
DataRateUp=20000 kbps
WanListMode=0
FECDown=6140400
FECUp=471
CRCDown=6
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 3:02, 19 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.1 dbm
PowerUp=6.4 dbm
AttainUp=28033
AttainDown=103020
ShowtimeStart=18
TotalStart=131
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=573
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

 

[IronRod]

The spectrum thing is really weird. The obvious way to get a spectral plot of the line would be to FFT the raw data that comes out of the front-end ADC, but that should really be a software process so it's odd that it's interfering with the physical connection. Even if the spectrum data was obtained separately to the usual signal path, the other path would always have to be physically connected so enabling the software process shouldn't make any difference.

I wonder if the spectrum process is enabling some hardware test mode that it's not supposed to? Maybe ASUS enabled a test pin when they were bench testing and forgot to take out the debug code. Unintentional toggling chip IOs can cause horrible interference to delicate RF signals.

I suppose the other thing it could be is that the spectrum software process is causing some additional signal processing hardware to switch on that's causing cross-talk with the modem front end. Or maybe if they're using a CPU to do the FFT maths and the extra processing activity is occurring at a frequency similar to the VDSL signal....that does seem a bit unlikely though.

Anyway, that's an excellent bit of detective work from you guys. I hope that this does turn out to be the culprit because it's an easy fix to turn off a software process....even for ASUS!

I've switched back to my BT OR modem to try to restore my download speed...I'm still running at about half the speed that I was before buying the ASUS POS and DLM doesn't seem to be playing nice with me at the mo.....14days on BT OR and I'm still stuck at 19M download

 

[Ixel]

The spectrum thing is really weird. The obvious way to get a spectral plot of the line would be to FFT the raw data that comes out of the front-end ADC, but that should really be a software process so it's odd that it's interfering with the physical connection. Even if the spectrum data was obtained separately to the usual signal path, the other path would always have to be physically connected so enabling the software process shouldn't make any difference.

I wonder if the spectrum process is enabling some hardware test mode that it's not supposed to? Maybe ASUS enabled a test pin when they were bench testing and forgot to take out the debug code. Unintentional toggling chip IOs can cause horrible interference to delicate RF signals.

I suppose the other thing it could be is that the spectrum software process is causing some additional signal processing hardware to switch on that's causing cross-talk with the modem front end. Or maybe if they're using a CPU to do the FFT maths and the extra processing activity is occurring at a frequency similar to the VDSL signal....that does seem a bit unlikely though.

Anyway, that's an excellent bit of detective work from you guys. I hope that this does turn out to be the culprit because it's an easy fix to turn off a software process....even for ASUS!

I've switched back to my BT OR modem to try to restore my download speed...I'm still running at about half the speed that I was before buying the ASUS POS and DLM doesn't seem to be playing nice with me at the mo.....14days on BT OR and I'm still stuck at 19M download

I see. Yeah, I hope it's this as well, as this is an easy fix.

Although FEC is rapidly rising, the CRC errors are 12 and ES is 7. Same sync rate and delay as previous post and the uptime is over 5 hours and 15 minutes.

I also took a small amount of time to re-build the gain table fetched from TC (making it into a compatible chart so I could see if there was severe interference like in the past). Well, I can't say there is at the moment by the looks of it.

Bitloading on DS2 band (roughly an hour ago):

 

[babis3g]

i am also reporting after running 2 times the new ini file running for 5 hrs with spectrum killed ... i did not had a single crc error for first time with bit swap on (adsl) & the snr did not dropped a single db)

Before i had 25 db and with bit swap on it did dropped down to 5!!! ( have screenshot way back posts)

It looks is much better with spectrum completely disable (killall -9 spectrum) thanks for finding the command

EDIT
i still have the connection with spectrum disabled (even longer than 5 hrs) via telnet to see when will start crc errors

 

[Ixel]

i am also reporting after running 2 times the new ini file running for 5 hrs with spectrum killed ... i did not had a single crc error for first time with bit swap on (adsl) & the snr did not dropped a single db)

Before i had 25 db and with bit swap on it did dropped down to 5!!! ( have screenshot way back posts)

It looks is much better with spectrum completely disable (killall -9 spectrum) thanks for finding the command

EDIT
i still have the connection with spectrum disabled (even longer than 5 hrs) via telnet to see when will start crc errors

Excellent.

If spectrum is truly our enemy at the moment, the cause of all this instability, then I wonder if there's a way of temporarily applying a cron task that issues 'killall -9 spectrum' every few minutes (until ASUS fix this or allow it to be disabled permanently by the end user - if they can't fix it).

What I'd love to do is be able to apply any changes I've made in TC permanently, so between reboots I don't have to manually re-apply the settings I specified. So far I haven't found a way of doing this .

But, there's one thing I think ASUS should have in their DSL settings page. Like on the Fritzbox, a method of specifying the INP value on the downstream (and possibly the delay in milliseconds as well). That would be extremely useful as an advanced user could then specify a permanent INP and delay value for the downstream that they find to be the level of performance vs stability that they want.

 

[babis3g]

The spectrum thing is really weird. The obvious way to get a spectral plot of the line would be to FFT the raw data that comes out of the front-end ADC, but that should really be a software process so it's odd that it's interfering with the physical connection. Even if the spectrum data was obtained separately to the usual signal path, the other path would always have to be physically connected so enabling the software process shouldn't make any difference.

I wonder if the spectrum process is enabling some hardware test mode that it's not supposed to? Maybe ASUS enabled a test pin when they were bench testing and forgot to take out the debug code. Unintentional toggling chip IOs can cause horrible interference to delicate RF signals.

I suppose the other thing it could be is that the spectrum software process is causing some additional signal processing hardware to switch on that's causing cross-talk with the modem front end. Or maybe if they're using a CPU to do the FFT maths and the extra processing activity is occurring at a frequency similar to the VDSL signal....that does seem a bit unlikely though.

Anyway, that's an excellent bit of detective work from you guys. I hope that this does turn out to be the culprit because it's an easy fix to turn off a software process....even for ASUS!

I've switched back to my BT OR modem to try to restore my download speed...I'm still running at about half the speed that I was before buying the ASUS POS and DLM doesn't seem to be playing nice with me at the mo.....14days on BT OR and I'm still stuck at 19M download

Just another update after a few hours. FEC out of control as expected, but CRC's are neglible on the downstream despite the very light level of interleaving I've currently applied at the moment (almost fastpath). In the past I don't recall being able to apply such a low level of interleaving to this sync rate/SNRM.

Thanks all

Well what ever is going on with the spectrum, hope they can locate possible internal issue

EDIT

i remember with the dsl n55u the spectrum was at the dsl setting page (next tab) and since than is been moved near to the live traffic monitors)

EDIT 2

The TBB monitor is seems much clear now
can not confirm 100% because here is coming busy time (peak time ) & TBB peaks as well higher latency & jitter ... if it is will report again morning hrs

 

[Ixel]

Almost 9 hours on a downstream of 54Mbps, INP 0, delay 3ms (almost fastpath):

near-end path0 fec:     38656226(52390310)
near-end path0 crc:     18(94)
near-end fec sec:       30577(38402)
near-end err sec:       10(73)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(193)
far-end path0 fec:      1731(479195)
far-end path0 crc:      0(1929)
far-end fec sec:        29(8208)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(676)
far-end ua  sec:        0(29479)
outDiscards=248
inDiscards=151
outBytes=2529412362
inBytes=2769385301
outPkts=19724775
inPkts=23046497
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.2 dB
SNRMarginUp=9.3 dB
AttenUp=0.1 dB
DataRateDown=53999 kbps
DataRateUp=20000 kbps
WanListMode=0
FECDown=38656226
FECUp=1731
CRCDown=18
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 8:54, 18 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.1 dbm
PowerUp=6.4 dbm
AttainUp=27999
AttainDown=104740
ShowtimeStart=18
TotalStart=131
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=573
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

As far as I can tell the bitloading on DS2 is still reasonably fine. I will bump the downstream sync rate up to 60Mbps within the next few hours, while maintaining an INP of 0 and a delay of 3ms for near fastpath.

Remember, I'm ignoring the FEC value as I don't trust it and I don't believe DLM bears it into consideration. My focus is on CRC, ES and SES.

 

[Ixel]

Another update, over 13 hours in on 54Mbps downstream, 0 INP and 3ms delay:

near-end path0 fec:     67342186(81076713)
near-end path0 crc:     29(105)
near-end fec sec:       45064(52889)
near-end err sec:       16(79)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(193)
far-end path0 fec:      2390(479854)
far-end path0 crc:      0(1929)
far-end fec sec:        53(8232)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(676)
far-end ua  sec:        0(29479)
outDiscards=488
inDiscards=198
outBytes=3915724874
inBytes=1700879504
outPkts=23621090
inPkts=27066679
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.3 dB
AttenDown=10.2 dB
SNRMarginUp=9.3 dB
AttenUp=0.1 dB
DataRateDown=53999 kbps
DataRateUp=20000 kbps
WanListMode=0
FECDown=67342013
FECUp=2390
CRCDown=29
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=13:03, 7 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.1 dbm
PowerUp=6.4 dbm
AttainUp=28042
AttainDown=106176
ShowtimeStart=18
TotalStart=131
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=573
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

Bitloading for DS2:

Slight bit of interference on DS2, but the error seconds and CRC errors remain low. When I nudge the speed up to 60Mbps I might also reduce the delay to 2ms to see what possible difference it has. I know 3ms virtually prevents the trickle of small CRC errors that I usually experience every 3 to 15 minutes (even on the HG612 I encountered that on fastpath). FEC is stupidly high but I'm ignoring that. Perhaps Openreach should've provisioned fastpath as a 3ms delay instead (at least on the downstream)? It does seem to make a massive difference to the minor trickling CRC errors without causing a noticeable latency increase when gaming.

 

[babis3g]

whatever internal conflict was with spectrum, i believe the bit swap (at least with me & adsl) still needs little adjust

From my screenshots up the bit swap when turned off (with spectrum disabled) reacts now the same as the broadcom modems

Once bit swap is enable it push the tones to the left (lower frequencies) ... i have seen it by now & at the tc console because after 5 hrs when the tool ended capturing at summary ... the bit tones where originally started at dsl startup, they have moved to left but with higher bits

How ever as it is (with spectrum process off ... i am up for first time with bit swap enabled for 14 hrs with not a single fec or crc error and the snr is still stable at 25 db and has not dropped a single db



I know my profile is with high snr target but ... now it works just as broadcom modem (same Max down rates/snr/errors) steady snr and when bit swap turned off -- the bit swap tones are similar with the broadcom modems
Sunday here with most people using the internet at peak time was a good test day

I think we will have development soon but now is coming Xmas, they may up for holidays ???

 

[Ixel]

whatever internal conflict was with spectrum, i believe the bit swap (at least with me & adsl) still needs little adjust

From my screenshots up the bit swap when turned off (with spectrum disabled) reacts now the same as the broadcom modems

Once bit swap is enable it push the tones to the left (lower frequencies) ... i have seen it by now & at the tc console because after 5 hrs when the tool ended capturing at summary ... the bit tones where originally started at dsl startup, they have moved to left but with higher bits

How ever as it is (with spectrum process off ... i am up for first time with bit swap enabled for 14 hrs with not a single fec or crc error and the snr is still stable at 25 db and has not dropped a single db

I know my profile is with high snr target but ... now it works just as broadcom modem (same Max down rates/snr/errors) steady snr and when bit swap turned off -- the bit swap tones are similar with the broadcom modems
Sunday here with most people using the internet at peak time was a good test day

I think we will have development soon but now is coming Xmas, they may up for holidays ???

Excellent. Yes, it's possible. Once I've done more testing here I will see what happens if I set bs wait_num to 0 instead of 1 (applicable to VDSL2 bitswapping only however). I'll be changing to 60Mbps with delay of 2ms in the next 30 minutes~.

I believe stopping/disabling the spectrum monitoring has somehow improved stability here as well, neglible CRC errors, no spikes and almost fastpath.

Unfortunately yes, it's possible ASUS will be away until after January 1st very soon (if not already).

 

[babis3g]

Basicly at least for my adsl profile connection when bit swap is enabled ... seems is doing unnecessary swapping ... again but ... it needs to test and a user with proper adsl2+ profile where all 512 tones will be in use ... with my profile the tones goes only up to 380 max

 

[babis3g]

Just to add ... if you still have reduced usb 3.0 disabled, an other time try now to enable it ... to me looks (according to my testings) it may helps better for the high fec errors & bit swapping

 

[Ixel]

Just to add ... if you still have reduced usb 3.0 disabled, an other time try now to enable it ... to me looks (according to my testings) it may helps better for the high fec errors & bit swapping

I see. Unfortunately it's already enabled, though wireless is disabled.