Anyone Using an Asus DSL-AC68U

bitsNbobs · 5 Apr 2015 at 19:11

Ixel said:
Beware the router can still say fastpath on the stats UI page when it's actually not fastpath, hence why your ping might still be higher than expected.

Yep still reporting things wrong in various areas.

Ixel said:
Regarding line attenuation, on the HG612 quite some time ago I have a screenshot of my pbParams data, clearly the ASUS is measuring the U0 attenuation (either line or signal, not sure which). However it might be calculating it a little lower than it should actually be.

U0 bank of stats are for the line way before they get to you, thats why the whole bank of them hardly vary at all, and why the power figures are minuses... or to make more sense of the Huawei poor formatting job (assuming this formats it correctly lol)....

Code:

VDSL Band Status	U0		U1		U2		U3
Line Attenuation(dB):	1.3	20.3	31.7	N/A	N/A	11.5	27.1	42.2
Signal Attenuation(dB):	1.3	20.2	31.6	N/A	N/A	12.3	26.8	42.2
SNR Margin (dB):	16.8	16.1	15.6	N/A	N/A	25.4	25.3	25.4
TX Power(dB):		-5.1	-22.7	5.6	N/A	N/A	9.1	7.3	6.5

Ixel said:
Obviously altering the DSL settings such as the transmit power offset will effect this. Another interesting fact is that if I reduce my offset too much (e.g. to get an ideal attainable near to the 20Mbps upstream sync rate limit) it will cause downstream error statistics to be worse,

Alters the tones and possibly re-allocates them, depending on the routine asus are using.

Ixel said:
such as increased errored seconds, severely errored seconds, FEC errors and/or CRC errors. So far the best setting that works for me appears to be +1 dB on the transmit power offset.

They should IMO just do away with that setting and fix it to allocate properly by iteself. All it does (as is obvious from some of the last few contributions

) is confuse people.

Ixel said:
My current DSL settings: http://i.imgur.com/2MoReXp.png

Code:

near-end path0 fec: 666233 near-end path0 crc: 28 near-end fec sec: 5797 near-end err sec: 10 near-end ses sec: 0 near-end los sec: 0 near-end ua sec: 0 far-end path0 fec: 589 far-end path0 crc: 94 far-end fec sec: 144 far-end err sec: 88 far-end ses sec: 0 far-end los sec: 0 far-end ua sec: 0 Opmode=ITU G.993.2(VDSL2) SNRMarginDown=8.5 dB AttenDown=10.3 dB SNRMarginUp=12.6 dB AttenUp=0.1 dB DataRateDown=62681 kbps DataRateUp=20000 kbps ADSLUpTime=2 days, 6:18, 50 secs ADSLActiveTime=0 min, 19 secs PowerDown=11.1 dbm PowerUp=5.8 dbm AttainUp=30249 AttainDown=104492 InterleaveDepth=1747 AdslStandard=VDSL2 AdslType=ANNEX_B

That's currently an average of around 12,000 FEC errors an hour, when I increased transmit power offset to +3 dB the FEC errors were almost continuously counting on the downstream. Reducing it to -5 dB also produced more FEC errors and CRC errors on the downstream. A setting of 0 dB (or default) resulted in a slightly higher rate of FEC errors compared to +1 dB at the moment. I'm leaving the settings as they are now and will wait for G.INP.

That now (attenuation figures, unless you have seriously tweaked something) when comparing to your old Huawei stats confirms what i thought its reading signal attenuation rather than actual line those figures are (allowing for device variation) as near to the U0 stats of the Huawei. It looks like its grabbing stats remotely at the cabinet or exchange rather than at your line end at sync time. Im not shocked that there is still various issues if its doing that, could also explain why it thinks everything is Fastpath LOL as it would be at the exchange its only at the cabinet DLM and interleaving gets applied. (at least i think thats the case still).

Ixel said:
Final note, G.INP will mask the stability problems on older firmware, so while ESNP is not required I imagine G.INP will be a bit more active without ESNP (provided the line previously suffered stability problems with the ASUS before G.INP was enabled on the line).

Its going to be a right mish mash now of trying to interpret what a line is actually doing with G.INP and quirk figures on some devices.

Ixel said:
Oh, I also believe bitswapping on VDSL2 is working. I initially synced with around a 7 dB SNRM on the downstream, and it's currently 8.5 dB. No noticeable activity at the cabinet/PCP recently either.

Only problem is that may be a remote and not LINE figure its reporting now though.

Ixel · 5 Apr 2015 at 20:10

babis3g said:
Hopefully Mr Jim @ Asus will take a look at the power transmit

Perhaps the AGC has something to do?

Have you tried what is best with transmit power for you line and play with AGC Gain?
(perhaps same settings as your screen shoot but change the AGC?)

I have briefly played with the agc gain as well. I don't feel there's anything wrong, it's just a matter of finding the best settings for your own line. I could've stayed with default settings (other than ESNP needing to be set to 'stable') but I chose to see if tweaking them made any further improvements.

babis3g · 5 Apr 2015 at 20:43

@ ixel ... ok thanks for the info

=========================
off topic

Have find around some varius hg612 stats (bit old ones) ... they may help or just for comparing

https://csdprojects.co.uk/HG612/2013_04_04_16:00.png
https://csdprojects.co.uk/HG612/2013_04_04_17:00.png
http://drlforum.co.uk/attachment.php?aid=114
http://drlforum.co.uk/attachment.php?aid=115
http://imgur.com/eM2vLCq
http://forum.kitz.co.uk/index.php/topic,12616.msg238460.html#msg238460

babis3g · 5 Apr 2015 at 23:06

bitsNbobs said:
That now (attenuation figures, unless you have seriously tweaked something) when comparing to your old Huawei stats confirms what i thought its reading signal attenuation rather than actual line those figures are (allowing for device variation) as near to the U0 stats of the Huawei. It looks like its grabbing stats remotely at the cabinet or exchange rather than at your line end at sync time. Im not shocked that there is still various issues if its doing that, could also explain why it thinks everything is Fastpath LOL as it would be at the exchange its only at the cabinet DLM and interleaving gets applied. (at least i think thats the case still).

Its going to be a right mish mash now of trying to interpret what a line is actually doing with G.INP and quirk figures on some devices.

Only problem is that may be a remote and not LINE figure its reporting now though.

Not to cost arguments ... Just from feeling to the underlined something tells me you may be right, perhaps Mr Jim @ Asus can check

EDIT
By the way ... it may me been paranoid ... but once (adsl here) turned tx power control (vdsl) to 1 ... it seems counts more crc down errors now ... than when it was disabled (more crc Up)

Elim · 5 Apr 2015 at 23:34

does anyone know how to check on the router when you lose connection to the exchange or when the internet has disconnected, or is that the dsl uptime field in dsl log

babis3g · 5 Apr 2015 at 23:44

Elim said:
does anyone know how to check on the router when you lose connection to the exchange or when the internet has disconnected. which part of router settings to check?

See at System Log > General Log

System Time
Uptime 2 days 12 hours 58 minutes 47 seconds

Then check at System Log > DSL Log

DSL Driver Version FwVer:5.5.1.127_A_A60901 HwVer:T14.F7_0.2
DSL Link Status up
DSL Uptime 0 days 3 hours 27 minutes 19 seconds

Alternative telnet cat /tmp/adsl/info_adsl.txt

Then you will see this (stats from previous poster up)

fwVer= FwVer:5.5.1.127_B_A60901 H

lineState=up
Opmode=
SNRMarginDown=7.3 dB
AttenDown=5.3 dB
SNRMarginUp=16.1 dB
AttenUp=0.4 dB
DataRateDown=79998 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=1433
FECUp=3716
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=4 days, 1:49, 24 secs
ADSLActiveTime=0 min, 17 secs
PowerDown=12.2 dbm
PowerUp=-4.5 dbm
ATURID=26005443434e0000
ATUCID=b5004244434da485
AttainUp=36824
AttainDown=103796
ShowtimeStart=17
TotalStart=85
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

and note the red highlighted

cuke2u · 6 Apr 2015 at 09:17

I'm not sure if that one is actually telling the truth as mine didn't change day to day from a similar figure...

babis3g · 6 Apr 2015 at 15:44

must be a bug then in the settings somewhere, dsl status should be with new uptime after each change, i think older firmwares (not remember which one, use to do this to not count the new dsl uptime)

bitsNbobs · 6 Apr 2015 at 18:36

babis3g said:
Not to cost arguments ... Just from feeling to the underlined something tells me you may be right, perhaps Mr Jim @ Asus can check

EDIT
By the way ... it may me been paranoid ... but once (adsl here) turned tx power control (vdsl) to 1 ... it seems counts more crc down errors now ... than when it was disabled (more crc Up)

If its NOW reading some remote stats rather than local end stats im not shocked the error figures have declined. There would not be as many, if any errors at the exchange/box/line card end or wherever the device is now grabbing stats from. Technically it may make the device more 'reliable' (thinks there are less errors so does less tone adjusting, less altering of bit loading etc, SRA isnt getting in the way etc etc etc making the device think everything is fine and stable and thus stays connected longer) Is it in a true sense "fixed" though.... absolutely NOT. Its been more tricked into staying connected than anything.

Ixel · 7 Apr 2015 at 14:08

Code:

near-end path0 fec:     1189827
near-end path0 crc:     54
near-end fec sec:       10669
near-end err sec:       17
near-end ses sec:       0
near-end los sec:       0
near-end ua  sec:       0
far-end path0 fec:      1118
far-end path0 crc:      179
far-end fec sec:        276
far-end err sec:        168
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=8.4 dB
AttenDown=10.3 dB
SNRMarginUp=12.6 dB
AttenUp=0.1 dB
DataRateDown=62681 kbps
DataRateUp=20000 kbps
ADSLUpTime=4 days,  7:23, 51 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.1 dbm
PowerUp=5.8 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=30214
AttainDown=104432
InterleaveDepth=1747
AdslStandard=VDSL2
AdslType=ANNEX_B

All seems fine with 4 days, 7 hours and 23 minutes~ of uptime still. No abnormally rising FEC errors. Unfortunately no positive changes by DLM yet, I guess I have a high caution counter.

Elim · 7 Apr 2015 at 14:25

getting around 1 a day disconnections on sky adsl on the asus while my sky hub router never had downtime hardly. strangely the asus router is giving me less CRC errors

another side question but why cant we enter 1500 for the mtu setting which is what my provider uses? max is 1492 on the settings

mjgr33n · 7 Apr 2015 at 15:21

FYI -

http://www.netgear.co.uk/home/products/networking/dsl-modems-routers/D6400.aspx

Appears Netgear now releasing (in the next few days) their first Consumer AC1600 WiFi VDSL/ADSL Modem Router.

They tend to use Broadcom chipsets and there wifi tends be very good for internal based antennas, have used the D6300 ADSL Router before and use a WAC120 Access Point in my room, all very good.

So if my ASUS ever dies or goes crazy, it is a possible option

Ixel · 7 Apr 2015 at 16:29

mjgr33n said:
FYI -

http://www.netgear.co.uk/home/products/networking/dsl-modems-routers/D6400.aspx

Appears Netgear now releasing (in the next few days) their first Consumer AC1600 WiFi VDSL/ADSL Modem Router.

They tend to use Broadcom chipsets and there wifi tends be very good for internal based antennas, have used the D6300 ADSL Router before and use a WAC120 Access Point in my room, all very good.

So if my ASUS ever dies or goes crazy, it is a possible option

Interesting.

Question, could you post your ping stats (e.g. to bbc.co.uk)? I've tried stating on the kitz forum that the ASUS DSL-AC68U does support G.INP and that you appear to be on it and working fine, but they aren't convinced at the moment. Posting ping stats may help in my quest to get the ASUS DSL-AC68U listed as a G.INP capable device on there. Thanks in advance.

(Or alternatively, stats from TC itself, as that will say for certain things about G.INP - e.g. framing parameters, bearer 1 being enabled, etc.)

cuke2u · 7 Apr 2015 at 16:43

The Netgear can be preordered on another well known shopping website for £149.99 for release on the 14/4...

danivtec · 7 Apr 2015 at 19:49

There doesn't appear to be any information I can find on what chipset the netgear uses at the moment.

mjgr33n · 7 Apr 2015 at 20:55

Ixel said:
Interesting.

Question, could you post your ping stats (e.g. to bbc.co.uk)? I've tried stating on the kitz forum that the ASUS DSL-AC68U does support G.INP and that you appear to be on it and working fine, but they aren't convinced at the moment. Posting ping stats may help in my quest to get the ASUS DSL-AC68U listed as a G.INP capable device on there. Thanks in advance.

(Or alternatively, stats from TC itself, as that will say for certain things about G.INP - e.g. framing parameters, bearer 1 being enabled, etc.)

Here you go, not sure if there are any other commands you want me to run in Telnet etc -

Code:

PING bbc.co.uk (212.58.244.20): 56 data bytes
64 bytes from 212.58.244.20: seq=0 ttl=53 time=11.372 ms
64 bytes from 212.58.244.20: seq=1 ttl=53 time=11.389 ms
64 bytes from 212.58.244.20: seq=2 ttl=53 time=11.539 ms
64 bytes from 212.58.244.20: seq=3 ttl=53 time=11.199 ms
64 bytes from 212.58.244.20: seq=4 ttl=53 time=11.545 ms

--- bbc.co.uk ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 11.199/11.408/11.545 ms

Code:

ASUSWRT DSL-AC68U_3.0.0.4 Tue Feb 24 02:32:56 UTC 2015
admin@DSL-AC68U:/tmp/home/root# cat /tmp/adsl/info_adsl.txt
outDiscards=553034
inDiscards=11854
outBytes=3858300353
inBytes=3574234913
outPkts=514058532
inPkts=535452255
fwVer= FwVer:5.5.1.127_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=
SNRMarginDown=6.8 dB
AttenDown=5.3 dB
SNRMarginUp=16.1 dB
AttenUp=0.4 dB
DataRateDown=79998 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=8255
FECUp=5725
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=6 days, 11:00, 21 secs
ADSLActiveTime=0 min, 17 secs
PowerDown=12.2 dbm
PowerUp=-4.6 dbm
ATURID=26005443434e0000
ATUCID=b5004244434da485
AttainUp=36836
AttainDown=103736
ShowtimeStart=17
TotalStart=85
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

babis3g · 7 Apr 2015 at 20:56

danivtec said:
There doesn't appear to be any information I can find on what chipset the netgear uses at the moment.

see first pages

AGGIORNAMENTO 24-03-2015
Nuovi modem-router xdsl wireless Netgear disponibili in Italia nel corso del 2015
D6400 (chipset vdsl2/adsl2+ bcm63168 by Broadcom) (In arrivo ad aprile 2015)

http://www.hwupgrade.it/forum/archive/index.php/t-2631463.html

They have some good info in there

============================

By the way ... mentioned the netgear

I have to say about the new ASUS DSL N17U

Asus bringing a compact adsl/vdsl unit (MediaTek MT7510 same as the dsl ac68u) ... 2,4G (300Mbps) beamforming with internal antennas, separate giga incoming wan, 2 usb 2.0 ... and asus throwed same dsl settings (nothing less) as the dsl ac68u

http://www.asus.com/Networking/DSLN17U/

Not sure when will be in UK but it seems a way lower cost alternative

Here in size compared with my dsl ac68u

It will bring some more in stock later but soon almost everywhere available in Europe
http://www.verkkokauppa.com/fi/product/22450/fqnhg/Asus-DSL-N17U-ADSL2-VDSL-modeemi

mjgr33n · 7 Apr 2015 at 21:00

danivtec said:
There doesn't appear to be any information I can find on what chipset the netgear uses at the moment.

No, I cannot find either, but Netgear do primarily use Broadcom for there modems and they have used them for there Telco VDSL ones, so I doubt they will use an unfamiliar manufacturer of chipsets for a new model.

So at a guess I would say 90% likely to be Broadcom, but anything is possible

babis3g · 7 Apr 2015 at 21:10

mjgr33n said:
No, I cannot find either, but Netgear do primarily use Broadcom for there modems and they have used them for there Telco VDSL ones, so I doubt they will use an unfamiliar manufacturer of chipsets for a new model.

So at a guess I would say 90% likely to be Broadcom, but anything is possible

Quote:
Originally Posted by danivtec
There doesn't appear to be any information I can find on what chipset the netgear uses at the moment.

see first pages

Quote:
AGGIORNAMENTO 24-03-2015
Nuovi modem-router xdsl wireless Netgear disponibili in Italia nel corso del 2015
D6400 (chipset vdsl2/adsl2+ bcm63168 by Broadcom) (In arrivo ad aprile 2015)
http://www.hwupgrade.it/forum/archive/index.php/t-2631463.html

They have some good info in there

trisp · 7 Apr 2015 at 21:14

So we were test subjects o goody...