Anyone Using an Asus DSL-AC68U

@ bitsNbobs
Just a thought because i have seen something similar at Asus forums for the dsl n66u
If you speak direct to Asus they may provide any tools you need - Not sure because they going to add in future adaptive QoS and perhaps some security tools (perhaps Network Protection by Trend Micro) ... but worth asking ;) Nothing to loose

EDIT
email right post below mine
 
Last edited:
RedBull2k said:
After i did a reboot the other day my sync came in at about 72, then after turning TCM off with the code you provided. My router gui was stating still 72, but when i run code in tcm to pull up the stats my sync was changed to 58,
Do you think with TCM disabled that it can effect sync? or do you think its dlm?
Click to expand...

I believe the GUI stops updating when you switch to use TCConsole mode.
 
RedBull2k said:
Anyone got that email address, so we can all mass send an email to him with our requests.

@ixel
After i did a reboot the other day my sync came in at about 72, then after turning TCM off with the code you provided. My router gui was stating still 72, but when i run code in tcm to pull up the stats my sync was changed to 58,
Do you think with TCM disabled that it can effect sync? or do you think its dlm?
Click to expand...

Disabling TCM will reduce your attainable sync.
 
babis3g said:
Yes for sure 100% especially the stats page
Perhaps because is been set to bridge mode the lan before the use of the TC Console (adslate bridgemode - if i remember correct)
Click to expand...
ok thanks that clears that up.

What about my sync changing when TCM is Disabled, for some reason i dont think its dlm,
 
RedBull2k said:
ok thanks that clears that up.

What about my sync changing when TCM is Disabled, for some reason i dont think its dlm,
Click to expand...

Already answered this above.

TCM is a type of convolutional code which utilises parity bits on each symbol within a continuous data stream. Its also a highly efficient form of modulation for data which is to be transferred over such mediums as the telephone line.

Trellis encoding works well for general background type noise. It has negligible data overheads for redundancy and instead uses complex constellations for mapping of the data path. The advantage is a higher data rate than with block encoding but it relies on the modem chipset to undertake more complex calculations and therefore a faster processor is required to avoid latency.

Whilst Trellis encoding may cause a tiny amount of buffering during the encoding and decoding stage it should be negligible on most decent modems and not cause any noticeable latency. The end result should be low error rates for environments experiencing low level repetitive noise as it detects patterns from noise sources and is able to correct these.

The net coding gain for TCM is said to be circa 3dB in most environments, although it must also be said it does not offer any advantage if the line is completely noise free. It should work best on longer lines which are more likely to pick up background noise from the environment.
Click to expand...
http://www.kitz.co.uk/adsl/error_correction.htm#Trellis
 
simoncraddock said:
It's always been something of a confusing grey area.

If I try to set up a manual WAN connection rather than select a pre-defined ISP selecting Annex A fails to connect, only B works here. I suggested long ago Asus issue a UK only firmware with everything that wasn't compatible be stripped out and added back in on a needs only basis, such as G.INP which is being rolled out.
Click to expand...

That is different to the N66U which, as I said, ignores the setting and reports ANNEX_A.


In typing a response on annexes, I've got a bit more detail and found it was even messier then I'd thought:

BT SIN 498: "The modem shall support 17MHz operation using band plan B8-11 (i.e. plan 998ADE17) as defined in Annex B of G.993.2"

[G.993.2 annex A has the NA bandplan, annex B has the European bandplans, annex C has the bandplan for Japan]

G.993.2 Annex B (defining the European bandplans) has B8-11 (a variant of 998) defined:
Short name = B8-11
Limit PSD mask (Long name) = 998ADE17-M2x-A
US0 type = A (US0 type A corresponds to Annex A of [ITU-T G.992.5])

G.992.5 annex A (referenced in the definition of B8-11) is "Specific requirements for an ADSL system operating in the frequency band above POTS".

Another US0 type is B (corresponds to Annex B of [ITU-T G.992.5]), where
G.992.5 annex B is "Specific requirements for an ADSL system operating in the frequency band above ISDN …"


I'd suggest the only real way to clarify these annex setting and reporting is to have them labeled as what they are for and which standard they are annexes of!
e.g.
bandplan region = G.993.2 Annex B (B meaning European bandplans)
underlying infrastructure = G.992.5 Annex A (A meaning US0 type is for POTS)


I had believed the ASUS annex setting and log were both the G.992.5 Annex for infrastructure being POTS or ISDN.
Your 68U "Annex A fails to connect, only B works" suggests the setting on the 68U may be the G.993.2 annex. Presumably when set to B, the annex reported in the DSL log is still A?
 
Last edited:
simoncraddock said:
Overnight mine has recorded just 50 CRC on the DS and 3 US for a 24hr period, which is probably the best I've seen on any router I've used in the past 8 months.
I'm connected to a ECI cabinet about 300 metres away.

As for settings...

Untitled.jpg
Click to expand...

I don't have that setting is it specific to the 68u? I have the ac66u.
 
The DLM intervention time is odd, it used to be between 2am to 7am in the morning here, but recently it has been at other times (such as around 10am, and infact today a moment ago when upstream interleaving was removed it happened at around 11:30am~). I wonder what's prompted the change in intervention time.
 
It seemed to change not long after the court case before Xmas when BT were forced to temporarily disable DLM. The issue of timing is a bit puzzling now because my last change took place around 9.30am. The logic behind it, one can only guess because the original timings were set to cause minimal disruption to end users by doing it when most are asleep.

Only thing I can think of is that resetting towards midday when noise margin is at it's highest gives best scope for higher connection speed.
 
Last edited:
Just like to share its not a complete 24hour cycle
Code: 
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.2 dB
SNRMarginUp=6.3 dB
AttenUp=0.1 dB
DataRateDown=61944 kbps
DataRateUp=18994 kbps
WanListMode=0
FECDown=138945983
FECUp=873
CRCDown=1
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=19:46, 30 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.6 dbm
PowerUp=3.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=20689
AttainDown=99984
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1324
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
tc>
 
simoncraddock said:
That only seems to happen from my own experience if you leave the Annex set to A/I/J/L/M in DSL Settings. If you set it to A then that will go away.
Click to expand...

Never know that may get rid of his FEC problem. I would not trust a single setting to be doing what it should do correctly without you actually setting it correctly.
 
A bit off topic, finally got myself a HG612 and unlocked it. Connected to ECI cabinet, no DLM intervention overnight (so far).

Since Link time = 1 days 7 hours 48 min 39 sec
FEC: 0 36
CRC: 14618 1
ES: 329 1
SES: 37 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

The DSL-AC68U can generate the same number of CRC errors in a couple of hours, but if this is indicative of the number of ES and SES compared to CRC then I might be OK with the DSL-AC68U and remaining on fastpath.

Trigger for DLM seems to be 2880 errored seconds in a 24 hour period, or 2 per minute. I'm way off that with the HG612 so maybe I'll give the DSL a(nother) chance. Still, would be nice if we could get this info on the GUI or from the text file.
 
now changed to annex A only, and it is now removed
Code: 
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.2 dB
SNRMarginUp=6.2 dB
AttenUp=0.1 dB
DataRateDown=62117 kbps
DataRateUp=18994 kbps
WanListMode=0
FECDown=1070
FECUp=0
CRCDown=0
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=0 min, 25 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.6 dbm
PowerUp=3.4 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=20538
AttainDown=98176
ShowtimeStart=19
TotalStart=58
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1324
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus
tc>Connection closed by foreign host
admin@DSL-AC68U:/tmp/home/root#
 
You must log in or register to reply here.
Back
Top Bottom