Anyone Using an Asus DSL-AC68U

Another update to say that FEC is rising at its usual pace. I'm more interested to see if the rate of errored seconds gradually becomes worse after a day or so though - like before.
 
Ixel said:
Another update to say that FEC is rising at its usual pace. I'm more interested to see if the rate of errored seconds gradually becomes worse after a day or so though - like before.
Click to expand...

Its even possible the bitswapping works but the algorithm after a certain time frame crashes, or does not function as it should if SNR fluctuates beyond a set limit. (im assuming over long periods of a few days that does indeed alter by a db or so).
Not sure if that is checkable within telnet or the TC console app. Would be nice if its possible to just monitor what bitswap is actually doing in real time (or as near to real time). Im going to have a bit of a more detailed investigation later on tonight despite not yet having the device at TC console and do some more reading up on what telnet commands are offered by the device and hopefully have maybe an odd suggestion.
 
5 days up straight with the latest firmware and I have been using vpn in to the office today without a drop and I used to get a couple a day at least. This new firmware seems to be working for me. I am sure there are some tweaks that could be done for a faster speeds and so forth but it seems stable and reliable to me.
 
bitsNbobs said:
Without having the device in my hands its a bit hard to say but im guessing the figure you have set relates to how much the db on any frequency has to change before bitswap interferes (adjusts things).

The higher the figure the more get shifted once bitswap comes into play. Which equates to more work for the device to do, which in turn can make the performance lag.

When its set at something like 1db the changes would be more frequent but more subtle (less noticeable) and thus less work for the device. This is not right but to simplify it more if you think of it like files on a computer, moving a 1kb file is done quicker and with less processing load than moving a 10000kb file.

If i had to guess the higher you set that figure the more even (level) a db chart (like the ones that have been posted earlier in the thread) will look but but the device is having to shift things in bigger lumps to do it.

Out of interest can you connect if you disable bitswap entirely and if so what effect does that have? If you can im guessing it either results in A) lower attainable and thruput rate (IE connection speeds) B) lower connection speeds + more errors or C) just more errors but same speed?

If DISABLING bitswap results in A) then bitswap is likely working properly, if its B) then bitswap works but not correctly. if its C) bitswap is not working properly at all.

Also does the device have a trelis or similar setting? and if so what happens if you enable or disable that?
Click to expand...

I am suspecting trellis & I have asked asus to add it ...they told me is enabled by default, however there is not any sin of it ... seems are not planning to let us control it manually

i have few posts back some screenshots of broadcom adsl modems vs asus
For my adsl connection 4 mbps caped (tones does not reach 512 like full 24 adsl) its much better having turn off bit swap

If i enable bit swap it drops the snr for my adsl connection
The 2158 firmware with low bit swap algo or rhythm bit swapping
https://www.asuswebstorage.com/navigate/s/5E7B00A7A638427AB0AB5BF0F1FB35234
it start low process (all good for me) but after time seems loosing its low rhythm and bit swapping change is fast again
How ever with enable bit swapping it does bring up the snr but not fully
(Old screenshot)


Other firmwares (previous) if i enabled bit swap the snr is falling & never does back to iso default unless bit swap is disabled
The one firmware at the link (with lower algo of bit swap) s the only one works little better but still needs improvement

From what i have understand either asus using its own bit swap & not from mediatek (which have experience as they supplying so many isps modems) or both running in the background as asus is bridging mediatek hidden xdsl hidden page
 
As far as I can tell they've removed the webserver on the Mediatek chip from 2155 onwards. I strongly suspect that ASUS have modified the Mediatek firmware, sadly to us I believe it's closed source.

Trellis is enabled according to TC, so they are right in that it's enabled by default. Personally I'm still sceptical of the bitswapping algorithm.

Based on above post by LordBarrass, I will give 2158 official a try later tonight.

EDIT: On 2158 official. For the sake of pure comparison I'm running similar connection settings that I had on the HG612 some time ago. Crosstalk on my line hasn't changed much since then either. I can also confirm that the 'spectrum' process might be causing instability even if I'm not on the spectrum monitoring page, reason I say this is because I initially forgot to kill the process and within 25 minutes I had a massive spike of CRC errors. Since killing it I've not had a repeat of the spike yet.

Current connection settings are...
- Maximum Sync Rate: 60 Mbps (Roughly the same sync rate I had on the HG612)
- Target SNRM: 14.0 dB (Roughly the same SNRM I had on the HG612)
- Delay: 1ms
- INP: 0
- Downstream Output Power Target: 12.5 - 13.0 dBm (ASUS seems to reduce power output in comparison to the HG612, so in order to closely match the HG612's reported downstream power output I've increased the target SNRM while setting a maximum sync rate just above what is achieveable and this has ensured I have now got a downstream power output of 13.0 dBm with not far from a 60Mbps downstream sync rate)

Will post statistics in the morning and my comparison to follow.
 
Last edited:
babis3g said:
nothing ... with firmware 2155 & later they have removed or changed the ip address
Click to expand...

They have more than likely just removed the code/scripting for the web interface entirely, if their was source code available for the more recent firmwares a simple compare to the older version GPL source i posted earlier would confirm or deny it. I suspect if they have removed just the interface it was done more as a way to eliminate that from possible issues rather than trying to limit people as the actual TC command line options still obviously work.

@babis3g have you at any (sorry if i missed the post) time played with any Seemless Rate Adaption setting (SRA) that can have weird effects like you chart shows.

SRA if there is a setting for that in recent firmwares for everyone AFAIK should be "off" or "disabled" NO UK ISP supports SRA on ADSL and i imagine it is the same for VDSL connections. SO anyone that has that set to "enabled" should alter that to "disabled".

A normally easy way on ADSL to tell if SRA is playing a roll in bad tone charts is in some stats recording software measure the noise margin every few (say 30) seconds. If it fluctuates madly by about 2-5(ish) db up and down and draws a wobbly chart line then the first thing you should check is that SRA is "disabled" as on ADSL the algorithm is not compatible with UK based ADSL services. In parts of Europe it is often used so i spose its possible that it has been enabled as the "default" setting.

@Ixel I have hope the issues can be solved, ive also discovered Cisco/Linksys have a TC Console app for some of their higher end gear, which has a few more options and looks like it may be compatible with the chipsets in the Asus, ive not found anywhere to download it though yet. Allows full scripting also which could be handy ;)
 
Last edited:
@bitsNbobs: Hopefully. Interesting, which Cisco/Linksys models support it? Are they by any chance VDSL2 capable or just ADSLx only?

-----

Here's an update. Initial comparison so far is good. I'm on firmware version 2158 (official) running near identical connection parameters to that of my HG612 when it was capped at 60Mbps fastpath by BT's DLM a while ago. Crosstalk has barely changed on my line since then which is good too. Note that the 'spectrum' process must be killed via telnet even if you don't access the spectrum monitoring page it seems - otherwise fastpath users will experience spikes of CRC errors.

On the HG612 I was averaging 25-30 errored seconds per hour. Currently on the ASUS I'm averaging around 20 errored seconds per hour.

Code: 
near-end path0 fec:     1762
near-end path0 crc:     219
near-end fec sec:       173
near-end err sec:       172
near-end ses sec:       0
near-end los sec:       0
near-end ua  sec:       0
far-end path0 fec:      55
far-end path0 crc:      4
far-end fec sec:        20
far-end err sec:        4
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

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

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=13.9 dB
AttenDown=10.4 dB
SNRMarginUp=12.4 dB
AttenUp=0.1 dB
DataRateDown=56035 kbps
DataRateUp=20000 kbps
FECDown=1762
FECUp=55
CRCDown=219
CRCUp=4
HECDown=0
HECUp=0
ADSLUpTime= 8:40, 12 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.0 dbm
PowerUp=6.2 dbm
AttainUp=29442
AttainDown=69860
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B

Interestingly you'll notice that the downstream FEC is being used even though the connection is fastpath, similar to how upstream seems to do that. Presumably it's related to using a higher SNRM.
 
Last edited:
bitsNbobs said:
@babis3g have you at any (sorry if i missed the post) time played with any Seemless Rate Adaption setting (SRA) that can have weird effects like you chart shows.

SRA if there is a setting for that in recent firmwares for everyone AFAIK should be "off" or "disabled" NO UK ISP supports SRA on ADSL and i imagine it is the same for VDSL connections. SO anyone that has that set to "enabled" should alter that to "disabled".

A normally easy way on ADSL to tell if SRA is playing a roll in bad tone charts is in some stats recording software measure the noise margin every few (say 30) seconds. If it fluctuates madly by about 2-5(ish) db up and down and draws a wobbly chart line then the first thing you should check is that SRA is "disabled" as on ADSL the algorithm is not compatible with UK based ADSL services. In parts of Europe it is often used so i spose its possible that it has been enabled as the "default" setting.
Click to expand...

I have test and with SRA enabled and disabled, there is not really much change but right now i am down in greece with adsl
Is only when bit swap enable will lower my SNR

When had my n55u enabling SRA it give me little lower ping but that was 2 years ago when i was with TalkTalk (adsl)
That seems is not the case with the ac68u

I have now disable the SRA & see if will make difference again with another firmware

My hg612 (i still have from TT, unlocked) it has SRA enabled & dynamic SOS (both must works together in combination) ... so it must be supported by dslam, BT & huawei or alcatel lucent (where they got most of their modems/dslams), i am sure have teamed very well for the UK FTTC & seems they have calculate/adjust each single setting/effect for their service ... so i don't think is enabled for nothing ... but the hg612 is designed for vdsl connections ... it seems no logic such an important setting (SRA/dynamic sos) not been in use when they know many lines will have noise ... but this is my own speculation

The long time i am watching the forums (including BT ones) because the hf612 have adjusted so smooth for UK FTTC, in most cases if are any issues they know must be from the line (that is why an engineer coming out in most cases) and not from modem
 
Last edited:
I appreciate you guys testing all of this. Hopefully it yields some decent info for ASUS to act on.

Its taken nearly 2 months for DLM to slowly move me back from when it dropped me to 40Mb sync up to 67 now after the last time I tested their firmware for them at the start of November. It's still not back to the original sync value (~71Mb) so I'm in no hurry to try out another firmware unless I know its fixed.
 
I'd say it's not fixed - applied 2158 firmware, killed spectrum process and within 10 minutes had > 11,000 CRC errors downstream. Fastpath now on both downstream and upstream as shown by InterleaveDepth=1. As I can only go by the text file stats, I can't see what this translated to in terms of ES and/or SES.

Not wanting another DLM intervention, reverted back to OR modem so hopefully nothing will change overnight.
 
Evil Shubunkin said:
I'd say it's not fixed - applied 2158 firmware, killed spectrum process and within 10 minutes had > 11,000 CRC errors downstream. Fastpath now on both downstream and upstream as shown by InterleaveDepth=1. As I can only go by the text file stats, I can't see what this translated to in terms of ES and/or SES.

Not wanting another DLM intervention, reverted back to OR modem so hopefully nothing will change overnight.
Click to expand...

Odd. Interesting though. I imagine if it's exactly like I had before I killed spectrum, probably up to 120 ES/SES combined.

I presume you had bitswapping enabled?
 
Just had a massive spike, no loss of sync yet however. This is on firmware version 2158 official.

Code: 
near-end path0 fec:     18770
near-end path0 crc:     5301
near-end fec sec:       423
near-end err sec:       422
near-end ses sec:       23
near-end los sec:       0
near-end ua  sec:       58
far-end path0 fec:      88
far-end path0 crc:      9
far-end fec sec:        36
far-end err sec:        9
far-end ses sec:        0
far-end los sec:        0
far-end ua  sec:        0

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

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=13.9 dB
AttenDown=10.4 dB
SNRMarginUp=12.4 dB
AttenUp=0.1 dB
DataRateDown=56035 kbps
DataRateUp=20000 kbps
FECDown=18770
FECUp=88
CRCDown=5301
CRCUp=9
HECDown=0
HECUp=0
ADSLUpTime=13:58, 0 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=13.0 dbm
PowerUp=6.2 dbm
AttainUp=29362
AttainDown=70104
ShowtimeStart=19
TotalStart=333
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
 
Ixel said:
@bitsNbobs: Hopefully. Interesting, which Cisco/Linksys models support it? Are they by any chance VDSL2 capable or just ADSLx only?
Click to expand...

Ive only found snippets on info on random help/faq style pages at the moment and a help video, they seem to produce a TC Console application for a wide variety of their gear from managed switches to teleconferencing, based on how similar some of the commands are i would not be shocked if there was a specific download which worked for the Asus. From what i can tell TC Console does not interact with the modem but the main chipset and WAN/LAN chipset. The only download pages i have found so far are for enterprise customers and they want you to log in with your enterprise customer ID before you can download.

....snipped for neatness only...

Ixel said:
Interestingly you'll notice that the downstream FEC is being used even though the connection is fastpath, similar to how upstream seems to do that. Presumably it's related to using a higher SNRM.
Click to expand...
out of interest for you next experiment so to speak ;) try...
fastpath on,
disable SRA if it is not already,
disable trelis and first see how that goes, if that goes ok then use TC Console to boost connection speed back to what it would be with trelis on (IE if with trelis off you lose 5Mb adjust via TC Console to give that 5Mb back). The FEC figure could be misleading and counting the errors corrected or discovered in the trelis algorithm, rather than actually reporting just what INP and/or interleaving is discovering, this would also explain partly why the figure sometimes goes to crazy amounts on the device for some people if its reporting errors corrected by things in addition to interleaving. I would not be shocked if when you kill spectrum its limiting what trelis is doing and thus reduces the error count.

Id also be interested in someones results running the device with trelis and bitswap both disabled though i know already as we discussed you get nowhere if you turn bitswap off.
 
babis3g said:
I have test and with SRA enabled and disabled, there is not really much change but right now i am down in greece with adsl
Is only when bit swap enable will lower my SNR

When had my n55u enabling SRA it give me little lower ping but that was 2 years ago when i was with TalkTalk (adsl)
That seems is not the case with the ac68u

I have now disable the SRA & see if will make difference again with another firmware

My hg612 (i still have from TT, unlocked) it has SRA enabled & dynamic SOS (both must works together in combination) ... so it must be supported by dslam, BT & huawei or alcatel lucent (where they got most of their modems/dslams), i am sure have teamed very well for the UK FTTC & seems they have calculate/adjust each single setting/effect for their service ... so i don't think is enabled for nothing ... but the hg612 is designed for vdsl connections ... it seems no logic such an important setting (SRA/dynamic sos) not been in use when they know many lines will have noise ... but this is my own speculation

The long time i am watching the forums (including BT ones) because the hf612 have adjusted so smooth for UK FTTC, in most cases if are any issues they know must be from the line (that is why an engineer coming out in most cases) and not from modem
Click to expand...

For ADSL in the UK no ISP uses SRA (seamless rate adaptation) the only ISP that ever did was UKonline and that was by request only, BE also at some point did limit tests but never made it an option beyond that.

I can not comment on FTTC but i would be shocked if SRA is enabled on that, even more so when the systems here in the UK no matter who you are with have some form of DLM applied. Having SRA also would not make sense, in fact it could confuse the DLM system. (Again maybe that apart from disconnects is why people have suffered at DLM with this device).

A modem should by default do nothing if SRA is NOT enabled by the service you are on OR does not have SRA activated, however with the DSL-AC68U this may not be the case, there has already just in this thread been numerous examples of the device still doing things it should not be doing unless you specifically disable things. (spectrum being the latest example) I have first hand experience of this with a past LLU ADSL provider and a Netgear DG834GT which if you enabled SRA would result in a wonky line for Noise Margin in Routerstats, if you disabled it though the recorded db noise margin line would be dead straight and the line would be more stable. This on a service with NO SRA as an option, so it should not had been doing anything whether i had it set on or off in the Netgear, but it did.

Another way you would know if SRA was working properly is the connection speed on your device will vary on a daily basis even though no resync occurs, thats what SRA is supposed to do, adjust the line rate to keep things stable, that is also why IMO it would confuse DLM and why IMO its highly unlikely it is enabled for even FTTC in the UK let alone most ADSL services. They would just confuse each other.

See...
http://www.kitz.co.uk/adsl/adsl_technology.htm#SRA
for related info about it increasing/decreasing the line connection speed and how at the time that was written UKOnline were the only ones that offered SRA.

For Greece i can not comment though i imagine if you speak greek a google search around regarding ISPs and services in Greece May reveal info on if they use SRA or not. I had a quick look but as i do not speak Greek i soon got tired of using Google translate and reading its robot translated English ;)
 
Last edited:
Thanks for the info ... :)

will be difficult to find out if SRA is enabled here as well because my line is caped and is always the same speed (4096) after each reboot,resynchronization, dc, power cut etc
... also most people here claiming no (not in use) but a local search did not help me a lot because most users has not the knowledge such you guys over there so any info are also speculations
I am not either so educated with SRA or bit swapping

Silly me changing so many broadcom modems for checking the bit swapping how reacts compared to asus, seems for a reason had in my mind the hg612 had SRA enabled (the other modem does by default)
After your latest reply i looked if had any records from the hg612 & Lucky i got this screenshot ( 3 about weeks ago) & SRA is disabled :eek: ... i am sure because i have adjusted the hg612 only for adsl line via its normal menu and have not touched bit swap, sra or other settings, just disabled the vdsl part once i was not using it
(the highlighted green is from other use of the screenshot)


Thinking now with SRA enabled (at asus) with heavy rain did drop my connection (falled down to 5db) & my snr target right now is 25db by isp

I will disabled SRA with current & next firmwares & see how my snr goes & hopefully will have a heavy rain again to see if will drop the connection again

It could be & the SRA ... asus having it on by default & looks like most isp worldwide not using it
 
Last edited:
No problem babis3g on ADSL its not a bad idea to play about with bitswap, Trelis and SRA. Even more so if your line is capped at around 4Mb AND especially if the line (if it were not for the ISP speed capping) could handle more. Different combinations are sure to produce different results and with trial and error you may come up with a set of options that helps the connection stay stable, killing the spectrum as you and Ixel have been doing also looks like that helps so i recommend keeping that killed also.

For FTTC i can not say for certain though once i get a highly configurable device such as the Asus i guess being a FTTC user i will soon find out. There is definately something on the Asus though be it trelis, bitswap, SRA, a combination of them all or them plus something else that affects noise margins and error correction from what i have seen of the testing in here so far.
 
Last edited:
At the moment just for stability im connected with my ac-68u to my Openreach modem.

Connected like this there is no button in the gui for the spectrum to scan. Unlike in modem mode there is a button to scan. Is there anything to this?

Edit: so i decided to connect it up the way it should be and also killed the spectrum process.

Code: 
tc login: admin
Password:
tc>tcapi get Info_Adsl lineState ;wan vdsl2 show mgcnt ;tcapi show Info_Adsl
up
outDiscards=0
inDiscards=0
outBytes=329734
inBytes=139460
outPkts=644
inPkts=598
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.9 dB
SNRMarginUp=9.1 dB
AttenUp=0.1 dB
DataRateDown=72038 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=38
FECUp=0
CRCDown=6
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=2 min, 35 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.5 dbm
PowerUp=4.9 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=25196
AttainDown=85984
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)


tc>tcapi get Info_Adsl lineState ;wan vdsl2 show mgcnt ;tcapi show Info_Adsl
up
outDiscards=0
inDiscards=0
outBytes=2069172
inBytes=257496
outPkts=2175
inPkts=1618
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.9 dB
SNRMarginUp=9.1 dB
AttenUp=0.1 dB
DataRateDown=72038 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=48
FECUp=0
CRCDown=8
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=3 min, 44 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.5 dbm
PowerUp=4.9 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=25258
AttainDown=86248
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

tc>tcapi get Info_Adsl lineState ;wan vdsl2 show mgcnt ;tcapi show Info_Adsl
up
outDiscards=0
inDiscards=0
outBytes=8199280
inBytes=599250
outPkts=6735
inPkts=4414
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.9 dB
SNRMarginUp=9.2 dB
AttenUp=0.1 dB
DataRateDown=72038 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=48
FECUp=0
CRCDown=8
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=5 min, 8 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.5 dbm
PowerUp=4.9 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=25310
AttainDown=86840
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

tc>tcapi wan vdsl2 show mgcnt ;tcapi show Info_Adsl
outDiscards=0
inDiscards=278
outBytes=33465651
inBytes=1437917
outPkts=24715
inPkts=14564
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=5.9 dB
AttenDown=9.9 dB
SNRMarginUp=9.2 dB
AttenUp=0.1 dB
DataRateDown=72038 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=197236
FECUp=0
CRCDown=15998
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=7 min, 59 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.5 dbm
PowerUp=4.9 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=25379
AttainDown=87812
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)

tc>tcapi get Info_Adsl lineState;sleep 1;wan vdsl2 show mgcnt;sleep 1;tcapi show
 Info_Adsl
up
outDiscards=0
inDiscards=313
outBytes=81515776
inBytes=3355775
outPkts=58173
inPkts=33700
fwVer= FwVer:5.5.1.126_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.0 dB
AttenDown=9.9 dB
SNRMarginUp=9.2 dB
AttenUp=0.1 dB
DataRateDown=72038 kbps
DataRateUp=20000 kbps
WanListMode=1
FECDown=637146
FECUp=0
CRCDown=53777
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=11 min, 5 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=12.5 dbm
PowerUp=4.9 dbm
ATURID=26005443434e0000
ATUCID=b5004946544eb204
AttainUp=25314
AttainDown=88152
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)
tc>
If you look at my CRC you will see with in 11mins it just gets bad.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom