Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ixel]

Here are the results from last night until now, with an agc_vref setting of 300 300 300 300.

Code: [Select]

near-end path0 crc:    8715(758)
near-end fec sec:       275(21315)
near-end err sec:       268(347)
near-end ses sec:       22(36)
near-end los sec:       0(0)
near-end ua  sec:       32(289)
far-end path0 fec:      4601(155675)
far-end path0 crc:      0(1120)
far-end fec sec:        48(4224)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(276)
far-end ua  sec:        0(13649)
outPkts=7828964
inPkts=10296575
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=72204 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=79164
FECUp=4601
CRCDown=8715
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 7:30, 15 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.0 dbm
PowerUp=4.8 dbm
AttainUp=25872
AttainDown=86380
ShowtimeStart=19
TotalStart=5296
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Had a burst of errors during the uptime somewhere, other than that it was mostly trickling of CRC's (around a rate of 1 every 2-3 minutes, which is about normal for my line at this speed :x).

The above was fastpath (INP 0, delay 1ms) with a target SNRM of 9.0 dB.

I've now reduced the target SNRM to 7.0 dB, the agc_vref setting to 250 250 200 250, and have increased delay to 3ms while keeping INP at 0. Will post results later today.

On the previous connection I would've lost sync usually long before the 7 hour uptime.

[Ixel]

Just updating this thread to mention a new firmware update has been released by ASUS, both officially and otherwise.

New firmware are listed on their website's support page, but particularly at the moment I'm using the unofficial beta release that geneva78 shared today over at the OCUK forum.

DSL-AC68U_3.0.0.4_376_2144-ga120ce8_DSL_1.0.1.9_1124.trx
https://www.asuswebstorage.com/navigate/s/ED60F694BDFC4F6FA4548FFC522FD5494

So far it's proving to work superb, no CRC's at all since uptime. Usually even with interleaving I get some ES/CRC by now. UPBO is disabled as I forgot to set it to auto before reconnecting the DSL cable, so my attainable upload is higher than usual at the moment. I've not done a factory reset either, might not be needed.

Code: [Select]

>tcapi get Info_Adsl lineState;tcapi show Info_Adsl;wan vdsl2 show mgcnt
up
near-end path0 fec:  15888(15888)
near-end path0 crc:    0(0)
near-end fec sec:       98(98)
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:      163(207517)
far-end path0 crc:      0(1160)
far-end fec sec:       3(4715)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(328)
far-end ua  sec:        0(14579)

fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=11.7 dB
AttenDown=10.4 dB
SNRMarginUp=12.4 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=15888
FECUp=163
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 1:29, 40 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.9 dbm
PowerUp=8.4 dbm
AttainUp=33399
AttainDown=107260
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
If by 6pm the FEC count and CRC is still extremely lower than usual then I will override the downstream DSLAM parameters (fastpath with up to 80Mbps sync rate) and test that. So far things are looking very good though, ASUS might have solved this at long last. Two other members on the OCUK forum also say no CRC's yet.

[babis3g]

Hi ixel, thanks for the update ... can you create with the new beta a TBB monitor? is not issue just for my knowledge, Thanks

[Ixel]

Hi ixel, thanks for the update ... can you create with the new beta a TBB monitor? is not issue just for my knowledge, Thanks

TBB monitor?

EDIT: I assume you mean the following.



EDIT 2: It doesn't appear to be graphing my IP, even though firewall allows pings.

EDIT 3: Fixed.

[babis3g]

yes thanks but at firewall you need enable responding ping from wan to work (should not ask for reboot just enable it)
here is mine (adsl) but if later on will not display any longer, is because i have dynamic ip so i will need to set a new one
Note the high green latency is because i am pinging from Greece  ( i am down here till xmas, perhaps longer) & here the small dslam is full so now coming peak time will be spikes but is normal for my connection


Done a reboot and now the monitor' s frequent red spikes are much less (well at the moment), a new one created because i have dynamic ip

[babis3g]

at network map of the asus copy the external ip & paste it at the monitor , also note it has 5 minutes delay so should appear monitoring soon
if you ip is dynamic then it will stop monitoring & you will have to create a new one

i can see is appearing working now

[Ixel]

at network map of the asus copy the external ip & paste it at the monitor , also note it has 5 minutes delay so should appear monitoring soon
if you ip is dynamic then it will stop monitoring & you will have to create a new one

i see is coming 

Fixed it. It was the firewall on the router which was misconfigured, perhaps due to the firmware update changing the settings somehow.

My network has a block of 8 public static IP's, so slight different configuration than the usual static or dynamic IP that is allocated to a connection.

[babis3g]

thanks for posting  , its working good, the monitor is clear .. you can remove it from the forum if you wish because we can see & your internet usage bandwidth  unless you don't mind

[Ixel]

The latest beta firmware from the ASUS web storage is proving to be excellent so far (other than the FEC count), I will be interupting the connection in the next hour or so to switch to fastpath on 80M sync. Not a single CRC error in over 10 hours! On the HG612 I get some ES/CRC under the same connection conditions.

Code: [Select]

>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show  Info_Adsl
up
near-end path0 fec:     37262819(37262143)
near-end path0 crc:     0(0)
near-end fec sec:       20405(20405)
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:      2407(209761)
far-end path0 crc:      0(1160)
far-end fec sec:        33(4745)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(328)
far-end ua  sec:        0(14579)
outDiscards=484
inDiscards=46
outBytes=702223663
inBytes=393361223
outPkts=3077299
inPkts=4094218
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=12.0 dB
AttenDown=10.4 dB
SNRMarginUp=12.5 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=37261351
FECUp=2407
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=10:11, 40 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.9 dbm
PowerUp=8.4 dbm
AttainUp=33488
AttainDown=111028
ShowtimeStart=18
TotalStart=18
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1517
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

[babis3g]

  i can see from the monitor fastpath is already on and seems from the first 30 min is going well?

[Ixel]

i can see from the monitor fastpath is already on and seems from the first 30 min is going well?

Yes. I've switched it to fastpath (not full speed yet though, will do that in the next hour, so still 49M out of 80M sync downstream).

Code: [Select]

>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show  Info_Adsl
up
near-end path0 fec:     0(52455869)
near-end path0 crc:     16(16)
near-end fec sec:       0(26771)
near-end err sec:       14(14)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(31)
far-end path0 fec:      1090(211333)
far-end path0 crc:      0(1160)
far-end fec sec:        8(4761)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(333)
far-end ua  sec:        0(14607)
outDiscards=278
inDiscards=82
outBytes=899890480
inBytes=1791472672
outPkts=3891256
inPkts=5244281
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=15.0 dB
AttenDown=10.4 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=48999 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=0
FECUp=1090
CRCDown=16
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=51 min, 56 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.7 dbm
PowerUp=4.8 dbm
AttainUp=25872
AttainDown=91512
ShowtimeStart=18
TotalStart=37
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
Similar results to the HG612 so far.

EDIT 1:
Went to 80Mbps sync rate on fastpath and the results were plenty of CRC errors. Either the router doesn't handle a 6dB SNRM on fastpath well (for downstream) or my line would just perform that way now due to crosstalk or some other interference - sadly can't verify this as the HG612 will be speed banded to 49Mbps sync rate.

I'm now testing 80Mbps sync rate with 8ms delay and 0 INP.



Despite high FEC's so far, absolutely no CRC's.

80Mbps, INP 0, Delay 8ms, DSL-AC68U_3.0.0.4_376_2144-ga120ce8_DSL_1.0.1.9_1124.trx:

Code: [Select]

>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show  Info_Adsl
up
near-end path0 fec:     97044(52552913)
near-end path0 crc:     0(78)
near-end fec sec:       164(26935)
near-end err sec:       0(44)
near-end ses sec:       0(7)
near-end los sec:       0(0)
near-end ua  sec:       0(108)
far-end path0 fec:      0(212902)
far-end path0 crc:      0(1160)
far-end fec sec:        0(4774)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(342)
far-end ua  sec:        0(14664)
outDiscards=293
inDiscards=1126
outBytes=1117761026
inBytes=3471247675
outPkts=5994115
inPkts=9249751
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.3 dB
AttenDown=10.4 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79969 kbps
DataRateUp=19999 kbps
WanListMode=0
FECDown=97044
FECUp=0
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=14 min, 31 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=4.7 dbm
AttainUp=25713
AttainDown=103156
ShowtimeStart=19
TotalStart=74
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=357
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

[Chrysalis]

ixel you will get crc errors on fast path, it simply will happen.

How many was you getting per hour? as you posted only 16 error which is nothing.  I wouldnt be deliberately putting my line on interleaving just because of some crc errors.  I would only do it if the actual service was been affected.

Also if you really think your line cannot handle 6db fast path then better to go 9db fast path instead of interleaving in my view.

[Ixel]

ixel you will get crc errors on fast path, it simply will happen.

How many was you getting per hour? as you posted only 16 error which is nothing.  I wouldnt be deliberately putting my line on interleaving just because of some crc errors.  I would only do it if the actual service was been affected.

Also if you really think your line cannot handle 6db fast path then better to go 9db fast path instead of interleaving in my view.

Yeah I understand that. I'll give 9 dB fastpath a try.

6 dB (80Mbps) fastpath for 12 min 40 sec gave me the following:

Code: [Select]

near-end path0 fec:     0(52455869)
near-end path0 crc:     7872(63)
near-end fec sec:       0(26771)
near-end err sec:       36(39)
near-end ses sec:       7(7)
near-end los sec:       0(0)
near-end ua  sec:       15(77)
EDIT 1: When I had the 16 errors, I also left the speed banding at 49Mbps which gave me an SNRM of 15.0 dB.

EDIT 2: The following are statistics on 9 dB fastpath for almost 15 minutes uptime so far.

Code: [Select]

near-end path0 fec:     520(52766504)
near-end path0 crc:     80(379)
near-end fec sec:       56(27746)
near-end err sec:       45(124)
near-end ses sec:       1(9)
near-end los sec:       0(0)
near-end ua  sec:       0(166)
EDIT 3: The following are statistics on 9 dB fastpath for 1h 35m~ uptime. Unfortunately while the CRC's are low and not effecting reliability or performance, the error seconds is high and if it continues at the current trend it will most likely exceed the MTBE for DLM I imagine.

Code: [Select]

near-end path0 fec:     4156(52770140)
near-end path0 crc:     401(700)
near-end fec sec:       626(28316)
near-end err sec:       269(348)
near-end ses sec:       1(9)
near-end los sec:       0(0)
near-end ua  sec:       0(166)
far-end path0 fec:      929(217866)
far-end path0 crc:      0(1160)
far-end fec sec:        17(4842)
far-end err sec:        0(969)
far-end ses sec:        0(0)
far-end los sec:        0(348)
far-end ua  sec:        0(14717)
outDiscards=305
inDiscards=1489
outBytes=1641448920
inBytes=879083683
outPkts=7529907
inPkts=10804049
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.9 dB
AttenDown=10.4 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=72876 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=4156
FECUp=929
CRCDown=401
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime= 1:35, 35 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.9 dbm
PowerUp=4.7 dbm
AttainUp=26050
AttainDown=87188
ShowtimeStart=19
TotalStart=112
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

[Chrysalis]

to give you a comparison here is mine so far today.

Latest 1 day time = 19 hours 10 min 9 sec
FEC:            0               53
CRC:            1293            5
ES:             114             5
SES:            3               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0

I think as long as the errors trickle in its fine.  Its a problem when you start getting consistent high amounts,  I occasionally get what I think is SHINE an ES where is like 500 or so CRC in one go, but that will be just 1 second and probably not a big deal.

Here my stats for yesterday which is higher.

Previous 1 day time = 24 hours 0 sec
FEC:            0               80
CRC:            3974            8
ES:             233             8
SES:            4               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0

I been using the central heating which I think is affecting my error rates, but even with that been the case, my service works fine.

[FriarJnr]

Can anyone please help! I just can't my DSL-AC68U to work with BT Broadband (it's not Fibre/Infinity). I've got what I believe are the correct setting but it just won't connect 

I guess my 1st question is should it work! I have also downloaded and patched up the latest firmware (DSL-AC68U_3.0.0.4_376_2072-gf4a1e74_DSL_1.0.1.7.trx).

Please, please help.

Thanks!