Anyone Using an Asus DSL-AC68U

Hi again

This is the reply from Asus about spectrum

Spectrum feature simply issue command and gather data from xDSL chip for display

Additionally, if Spectrum indeed caused CRC/FEC errors then probably due to while gathering data used too much xDSL chip CPU resource, we will fine tune/ enhance Spectrum feature
Click to expand...

They have provide a beta with spectrum command disabled & new bit swap algorithm for testing (i can see now Ixel already tried the new bit swap algorithm with no success)

@ Ixel

You should email Mr Paul Lee ASP to explain , because either my English is not good & did not understand what i am talking about or Asus just not believe the spectrum or what ever effect/conflict is happening in there causing issue
 
Last edited:
babis3g said:
Hi again

This is the reply from Asus about spectrum



They have provide a beta with spectrum command disabled & new bit swap algorithm for testing

@ Ixel

You should email Mr Paul Lee ASP to explain , because either my English is not good & did not understand what i am talking about or Asus just not believe the spectrum or what ever effect/conflict is happening in there causing issue for dlm to kicK UK users
Click to expand...

Ok I'll email him this morning to confirm that my connection is much more stable without spectrum running. I've had no issues since killing it, so it has to be caused by that.
 
ASUS (Paul) replied to me earlier today with two firmwares to test, one with the original bitswap and the other with the new bitswap (both have spectrum removed). I will be testing the new bitswap with spectrum removed tonight.

Also, regarding the high FEC, they gave a technical explaination which I thought is useful and I don't believe they'd mind me quoting it here (if they do I'll happily remove it):
Please note that the root cause of high FEC is Noise. Firstly, we assume that there is no Noise and the channel is perfect, the Receiver(Modem) get the constellation point is the exact point(we call it golden point for the time being) that the Transmitter(DSLAM) sent, so there is no FEC at all.

Secondly, there is slight noise and the channel is not perfect, the Receiver(Modem) get the constellation point is not the point that the Transmitter(DSLAM) sent, if Receiver(Modem) get the point is very close to the Transmitter sent than other constellation point, then the channel coding(such as RS code and decode) can correct it to the golden point, so FEC will be produced which is normal.
Click to expand...
 
to me it looks the spectrum command still needs to be disable? even the spectrum removed?
can not wait your report :)
its just when command is totally disabled my snr it looks not fallen & has fall slightly so the command may still work in the background
 
Last edited:
babis3g said:
to me it looks the spectrum command still needs to be disable? even the spectrum removed?
can not wait your report :)
Click to expand...

Paul also said that the instability shouldn't happen unless you're on the spectrum page while it's refreshing, as apparently it doesn't fetch any data unless you're on that page. I'm not entirely sure but I think I recall at one point not touching that page and at the time not killing spectrum (just shortly after you discovered that it was causing an issue and I started to test it here). I will however not run the killall command on the new firmware, but I will check to see if spectrum is running in the background.

It won't be for another 8 hours or so I expect, unfortunately, as the internet here's busy most of the day and evening.

In the meantime here's another statistics update - all is fine still, so I'm fairly confident that the spectrum monitoring is causing the instability now:
Code: 
near-end path0 fec:     87087820(87069097)
near-end path0 crc:     754(580)
near-end fec sec:       42336(42328)
near-end err sec:       131(123)
near-end ses sec:       8(8)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      6933(503232)
far-end path0 crc:      0(1944)
far-end fec sec:        115(8551)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(691)
far-end ua  sec:        0(30453)
outDiscards=666
inDiscards=666
outBytes=3591029031
inBytes=3727296860
outPkts=6247749
inPkts=5008609
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.9 dB
AttenDown=10.3 dB
SNRMarginUp=6.1 dB
AttenUp=0.1 dB
DataRateDown=79993 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=87087820
FECUp=6933
CRCDown=754
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=17:24, 31 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.9 dbm
PowerUp=4.6 dbm
AttainUp=25317
AttainDown=109300
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=289
AdslStandard=VDSL2
AdslType=ANNEX_B

I'm not entirely sure if the new bitswap is performing better than the old bitswap however. SNRM has dropped today, either due to rain conditions outside (not likely though) or someone else has been connected up to the FTTC service here (crosstalk).
 
well if you are almost fast path and still not disconnections it must be ok now with this beta ... i will wait to see your report (so ALL members ) by time (8 hrs or a day) ... as with my adsl line, is good weather here (for December) so i can not understand now

About bit swap, yes i think the bit swap, it was better with older firmware, how ever i am still running it now as my adsl has not dlm to worry but is not bad, just the older version better

Thank You
 
EDIT

i think will show up if the beta works ok - if you apply (the one with spectrum off & old bit swap) fast path 0 & INP 2-3 ms, like last time
 
Loss of sync a few minutes ago, not sure if it's related to the new bitswap or other conditions. However, I'm more going on the side of that it could be the new bitswap, as my SNRM has returned to what it was since re-syncing. Downstream power is the same as well.

Code: 
near-end path0 fec:     92234(100409553)
near-end path0 crc:     3(1266)
near-end fec sec:       57(48618)
near-end err sec:       1(238)
near-end ses sec:       0(26)
near-end los sec:       0(0)
near-end ua  sec:       0(33)
far-end path0 fec:      0(503646)
far-end path0 crc:      0(1944)
far-end fec sec:        0(8564)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(695)
far-end ua  sec:        0(30481)
outDiscards=0
inDiscards=729
outBytes=3841269770
inBytes=70464443
outPkts=6927616
inPkts=5671953
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.3 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79972 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=92234
FECUp=0
CRCDown=3
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=5 min, 25 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=12.8 dbm
PowerUp=4.4 dbm
AttainUp=25143
AttainDown=105100
ShowtimeStart=18
TotalStart=37
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=145
AdslStandard=VDSL2
AdslType=ANNEX_B

I will go back to the original bitswap without spectrum later this evening.
 
update

i have tried both betas ... the snr will start dropping 4-5 bd even if i kill spectrum via command
I returned to _2155 still the same even used command to kill the spectrum
master reset with 2155 still the same
The TBB monitor all times will have little more jitter than usual

I put back a tp link and all fine, no drop of snr and clear monitor

Will try again tomorrow one more time ... it could be just the the day ... for 2 days i was testing _2155 with command to kill the spectrum the snr was fine

i wait for Ixel report
 
Last edited:
Update

During the swap with an other modem for about 30-45 min i have swap back to asus and it looks woks fine only 1 db down and the TBB monitor clear

it seems like or cpu was overworking or because swapping firmwares effect it
 
babis3g said:
update

i have tried both betas ... the snr will start dropping 4-5 bd even if i kill spectrum via command
I returned to _2155 still the same even used command to kill the spectrum
master reset with 2155 still the same
The TBB monitor all times will have little more jitter than usual

I put back a tp link and all fine, no drop of snr and clear monitor

Will try again tomorrow one more time ... it could be just the the day ... for 2 days i was testing _2155 with command to kill the spectrum the snr was fine

i wait for Ixel report
Click to expand...

Will be upgrading to the 2158 original bitswap without spectrum in a few moments. On the current version I have (2158 with new bitswap and spectrum not removed) I keep occasionally getting the following while leaving TC open for hours at a time (didn't on other firmwares tested so far):
Code: 
qdma_bmgr.c [444]: There is no data available in IRQ queue. irq value:ffffffff, irq ptr:a3eb6418 TIMEs:2
qdma_bmgr.c [444]: There is no data available in IRQ queue. irq value:ffffffff, irq ptr:a3eb65c8 TIMEs:2

I have to restart TC to gain access again.
 
It can't be, as I'm not yet running the version that has spectrum removed. It didn't do this on 2155 with spectrum existing but killed (original bitswap).
 
I'm currently on 2158 with the bitswap change, but with spectrum still in it. I'm just about to change to 2158 with original bitswap from 2155, but with spectrum removed. After a day or so of using that I'll then try 2158 with the new bitswap, but with spectrum removed.
 
I've updated, but I've noticed something possibly interesting regarding FEC (or it might just be a fluke and happen later on). When I first connected FEC started to rise rapidly instantly, but then I thought I'd increase the target SNRM to a nice round number, e.g. from 8.3dB (as max sync rate is 80Mbps which I'm getting with spare SNRM) to 9.0dB. So, I changed the target SNRM to 9.0dB and so far the FEC is extremely low - perhaps it's just a fluke, will know in the morning.

Anyway, here's my initial statistics for 80Mbps downstream at 9.0dB target SNRM, INP 0, delay 4ms:
Code: 
near-end path0 fec:     122(30561)
near-end path0 crc:     0(0)
near-end fec sec:       3(19)
near-end err sec:       0(0)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(32)
far-end path0 fec:      0(505672)
far-end path0 crc:      0(1944)
far-end fec sec:        0(8600)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(704)
far-end ua  sec:        0(31246)
outDiscards=0
inDiscards=1
outBytes=12677723
inBytes=13170110
outPkts=20680
inPkts=19669
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=9.0 dB
AttenDown=10.3 dB
SNRMarginUp=6.6 dB
AttenUp=0.1 dB
DataRateDown=79157 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=122
FECUp=0
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=6 min, 30 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=4.7 dbm
AttainUp=25560
AttainDown=95816
ShowtimeStart=19
TotalStart=37
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=161
AdslStandard=VDSL2
AdslType=ANNEX_B

Will update again in the morning.

Oh, and the spectrum process hasn't started automatically.
 
Here's an update, same settings as previous reply.

Code: 
near-end path0 fec:     143699(173516)
near-end path0 crc:     412(316)
near-end fec sec:       555(568)
near-end err sec:       80(77)
near-end ses sec:       3(3)
near-end los sec:       0(0)
near-end ua  sec:       0(32)
far-end path0 fec:      3048(508720)
far-end path0 crc:      0(1944)
far-end fec sec:        48(8648)
far-end err sec:        0(1447)
far-end ses sec:        0(0)
far-end los sec:        0(704)
far-end ua  sec:        0(31246)
outDiscards=9828
inDiscards=425
outBytes=3986001326
inBytes=1126293749
outPkts=4183539
inPkts=3570774
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.3 dB
SNRMarginUp=6.6 dB
AttenUp=0.1 dB
DataRateDown=79157 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=143699
FECUp=3048
CRCDown=412
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 8:45, 29 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.8 dbm
PowerUp=4.7 dbm
AttainUp=25467
AttainDown=96112
ShowtimeStart=19
TotalStart=37
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=161
AdslStandard=VDSL2
AdslType=ANNEX_B

FEC remains nice and low still with the higher target SNRM, so perhaps it's more ideal to have a 9.0dB+ SNRM to keep that number somewhat under control?

SNRM is also fine, having only dropped 0.2dB~ from the original SNRM of 9.0dB. I'm currently more convinced the newer bitswap isn't working as good as the original bitswap. Later tonight I will switch to the newer bitswap without spectrum and test that.
 
You must log in or register to reply here.
Back
Top Bottom