Print

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

[Ixel]

Hi all,
It's been a while since I last used the ASUS DSL-AC68U. If anyone remembers, I was the person who discovered the various commands that overrode the downstream configuration via TC (e.g. forced fastpath with 80Mbps downstream no matter what the DSLAM said) on VDSL2/FTTC.

Well, after so many firmware updates since I last tried it I thought I'd try it out again and initially with default settings it's sadly no different to what it was the last time I tried it on an ECI DSLAM without G.INP support. However, I've observed after tweaking around with the settings that bitswap being enabled seems to be causing the instability. It's not concrete so far since I need more time to be 100% certain but it seems to certainly help if I actually disable bitswap. I've barely had CRC errors for a quite some time with bitswap disabled, compared to a much higher amount of CRC errors potentially resulting in loss of sync as soon as bitswap is enabled.

At the time of writing this post I'm now testing:

• DSL modulation: VDSL2
• ANNEX Mode: Annex A
• DLA: disabled
• Stability Adjustment: 10 dB
• VDSL Profile: 17a multi mode
• Bitswap: disabled
• SRA: disabled
• G.INP: enabled (though not supported on ECI at this time)
• G.vector: disabled
• ESNP: stable
• RX AGC Gain Adjustment: stable (394)
• Tx Power Control: -3 dB (though I don't think Tx Power Control has anything to do with the downstream instability, eventually I will try it disabled)

This is using firmware:

• DSL Firmware Version: 1.0.4.1
• DSL Driver Version: FwVer:5.5.2.7_A_A60901 HwVer:T14.F7_0.1

Interestingly two other posts I came across on other forums have had similar observations with bitswap. If it's true then it's not really the MediaTek chipset that's at fault but rather the algorithm it uses for bitswap is poorly designed. Those on G.INP won't notice problems however since G.INP will correct them fairly quietly.

I will continue testing for another 24-48 hours or so with the current settings. After that I will lower the SNRM target to 9 dB and observe how CRC errors are for another 24-48 hours.

Hopefully someone still with an ASUS DSL-AC68U might find this information useful. I'll post another update soon.

[Chrysalis]

yeah either a poor bitswap algorithm or its a bug reversing the actual status so disabled means enabled and vice versa.

[j0hn]

This was a very expensive paperweight in my house.
I recently discovered I can install Merlin on it, essentially turning it into a 2nd RT-AC68U.

The fact you can set it to Annex A and get a connection shows MediaTek are useless, as OpenReach DSLAMs only connect on Annex B.

Though thinking about this modem again I may try force fastpath to increases the ES and try force DLM to take action on my line as I'm on a Huawei cab with interleaving stuck. It may just get DLM to finally try enabling G.INP.

[Ixel]

Chrysalis: Interesting idea, so I just compared a small snapshot (only 5 minutes but surely at least one of the bits would've changed). All downstream bits were identical from the snapshot 5 minutes ago to the snapshot now (I didn't use the graph, I retrieved the raw data).

j0hn: Yeah, I had considered that at one point. Yeah, it's a bit silly that I have to set annex A when it's actually B. I can't sync when I've tried annex B (as if the settings for annex mode are actually reversed).

[Ixel]

For anyone interested in my results so far, while keeping bit swapping disabled it appears I've had no abnormal spikes in CRC errors. Just a small amount which I'd expect. I'm still remaining fairly conservative however.

More than 7 hours 45 minutes ago (at the time of writing this post) I've had the following settings in place:

• DSL modulation: VDSL2
• ANNEX Mode: Annex A
• DLA: disabled
• Stability Adjustment: 6 dB
• VDSL Profile: 17a multi mode
• Bitswap: disabled
• SRA: disabled
• G.INP: enabled (though not supported on ECI at this time)
• G.vector: disabled
• ESNP: stable
• RX AGC Gain Adjustment: 100 (custom)
• Tx Power Control: -4 dB

This is using firmware:

• DSL Firmware Version: 1.0.4.1
• DSL Driver Version: FwVer:5.5.2.7_A_A60901 HwVer:T14.F7_0.1

Because I'm using a fairly reduced Tx Power Control setting, temporarily, I have disabled UPBO or I may find I might not be able to sync due to having no bits for the upload sync rate. The manual reduction in power, in order to try and compensate but also determine later on if Tx Power Control has a role in the instability, has made the upload sync rate not far from what I'd normally get with UPBO enabled. I will re-enable UPBO and set Tx Power Control to disabled (0 dB offset) for the next test in 48-72 hours while keeping all other settings as they are. For now I will see how it copes with the current settings.

Finally, due to the fact I'm not certain how stable the connection might be at 6 dB SNRM downstream without bit swapping I've temporarily reduced the AGC setting to 100 (custom value, what I consider 'super stable') which has subsequently caused the modem to stop using some tones at the far end of D3 which were around 10 dB SNR at best. I'm getting around the same sync rates my connection would normally get on the DrayTek Vigor 2860ac.

TLDR: So far it's definitely looking likely that the bit swapping algorithm is flawed.

[willc]

good to see u back Ixel 

there is custom fw for the 68u,dunno if i can post it here so i sent u the link on skype.
how u didn't see that the bearers are inverted in g.inp mode??? u played with the console more than others i think.

[Ixel]

Thanks and I didn't realise the G.INP output was mixed up since I've not had G.INP working on this modem when ECI DSLAM's initially had G.INP enabled. I hope some day they will get G.INP again before ASUS officially and completely gives up supporting this product (in case G.INP on this device still doesn't work with ECI DSLAM's).

Finally I'm now testing UPBO enabled with Tx Power Control +1 dB and Rx AGC Gain Adjustment at 50. I'm trying to closely match the DrayTek's CRC errors based on a certain uptime, the bit loading and finally sync rate even though I'm pushing out a little more power on the upstream (as I want to confirm if Tx Power Control has much of a role in causing instability, which so far it doesn't appear to).

I also felt that the Rx AGC Gain Adjustment setting was too high (with the lowest offered by ASUS being 'stable' at 384) and could easily be a bit lower, I feel a setting between 50-100 is best for non-G.INP connections and those with long/noise sensitive lines. A setting of 100, when I tried it, seems to closely match my DrayTek's sync rate. I will be testing 80 next time.

So far after 7 hours 44 minutes of uptime I've had only a handful of CRC errors. Bitswap remains disabled.

More than 7 hours 44 minutes ago (at the time of writing this post) I've had the following settings in place:

• DSL modulation: VDSL2
• ANNEX Mode: Annex A
• DLA: disabled
• Stability Adjustment: 6 dB
• VDSL Profile: 17a multi mode
• Bitswap: disabled
• SRA: disabled
• G.INP: enabled (though not supported on ECI at this time)
• G.vector: disabled
• ESNP: stable
• RX AGC Gain Adjustment: 50 (custom)
• UPBO: enabled
• Tx Power Control: +1 dB

This is using firmware:

• DSL Firmware Version: 1.0.4.1
• DSL Driver Version: FwVer:5.5.2.7_A_A60901 HwVer:T14.F7_0.1

The ultimate test, once I've finished fine tuning the settings every 24-48 hours, will be to see if the modem is capable of remaining stable for a week or more.

[Ixel]

While an Rx AGC Gain Control setting of 50 offers even more stability and resistance versus CRC errors on downstream I've found that a setting of 100 is fairly close to how my DrayTek Vigor 2860ac performs. I've therefore returned it to 100 early this morning.

I'm trying bitswap again, obviously the moment I enabled bitswap I got instability fairly quickly. However, I'm now trying different bitswap parameters.

New parameters:

Code: [Select]

wan vdsl2 set bs_param 3072 768 2 1 1 4

6.0 dB target
1.5 dB trigger
2 scanned tones
1 wait count
1 scanned table start index
4 scanned table end index
Compared to the default of:

Code: [Select]

wan vdsl2 set bs_param 3072 1536 256 1 1 512

6.0 dB target
3.0 dB trigger
256 scanned tones
1 wait count
1 scanned table start index
512 scanned table end index
While the new parameters swap less bits at a time, it seems significantly more stable than the default bs_params. I need more time however, maybe even fine tune the trigger a bit more (perhaps 1.0 dB instead of 1.5 dB).

[Chrysalis]

Ixel following your tests I ran a short test of no bitswapping on a zyxel unit (the 3924). Yes it seems on broadcom devices disabling bitswapping works. Can verify in the bitswap data.

I was planning to give it 24 hours but CRCs got moderatly high so was abandoned after a few hours.

I expect if a line is only in normal conditions so no huge swings of snrm or new crosstalk, then one can get away without bitswapping, however if a line is hit with a change of snrm whether that been external interference or crosstalk, then without bitswap a modem cannot do anything, so I would expect huge amounts of errors followed possibly by a loss of sync so it can correct itself.  Even if my test yielded good results I wouldnt leave my line running for months on end without bitswapping, I would see it as a disaster waiting to happen.

[Ixel]

Ixel following your tests I ran a short test of no bitswapping on a zyxel unit (the 3924). Yes it seems on broadcom devices disabling bitswapping works. Can verify in the bitswap data.

I was planning to give it 24 hours but CRCs got moderatly high so was abandoned after a few hours.

I expect if a line is only in normal conditions so no huge swings of snrm or new crosstalk, then one can get away without bitswapping, however if a line is hit with a change of snrm whether that been external interference or crosstalk, then without bitswap a modem cannot do anything, so I would expect huge amounts of errors followed possibly by a loss of sync so it can correct itself.  Even if my test yielded good results I wouldnt leave my line running for months on end without bitswapping, I would see it as a disaster waiting to happen.

I see, yeah I agree, this is partly why I'm trying to see if I can actually fix the bitswapping issue with the DSL-AC68U. I'm closely monitoring the debug output for bitswapping as well as the graphs shown on the web UI. I feel at the moment I'm having success but I need to run it for more time and try a few different settings to see what kind of impact they have on bitswapping, CRC errors, errored seconds, SNRM and finally any loss of sync. Certainly seems far more stable for my line with running the bs_params that I mentioned in my previous reply here. Maybe it was simply just trying to swap too many bits at once or maybe instead just waiting for too many bits to be ready to swap hence CRC errors? Who knows.

[Ixel]

Something worth noting is that it seems fairly clear the errored seconds and severely errored seconds are counted incorrectly on this device (at least on downstream, perhaps upstream error counters are taken solely from DSLAM?).

Here's an example of what I mean (for downstream) after nearly 6 hours now (on the 3.0 dB trigger bs_params, stated below):

Code: [Select]

ErroredSecs: 19
SeverelyErroredSecs: 14
near-end FEC error fast: 0
near-end FEC error interleaved: 44394760
near-end CRC error fast: 0
near-end CRC error interleaved: 15
near-end HEC error fast: 0
near-end HEC error interleaved: 0
As you can see, FEC errors are stupidly high but ignoring that for the moment you'll see I've had 15 CRC errors and 0 HEC errors. How can that equate to 19 ES and 14 SES? Seems impossible if you ask me.

So, what I need to hope really is that the DSLAM is counting things differently, the only downstream error counter I can really somewhat rely on is the CRC errors. If DSLAM is counting ES/SES differently to the MediaTek chipset's firmware then I have nothing to worry about in regards to DLM.

In regards to the bitswap testing... The previous settings were stable with some errors but minor in comparison to what the default bitswap parameters (bs_params) do! I've tried 1.0 dB as the trigger but I think it was actually worse ironically. I barely saw any bitswapping when I thought it should've done (and often saw it being cancelled infact). So, I'm now trying a trigger of 3.0 dB (which is the default). This means the only bs_params settings changed are the scanned tones (2) and the scanned table end index (4). Bitswapping appears to be working fine with these parameters.

New parameters:

Code: [Select]

wan vdsl2 set bs_param 3072 1536 2 1 1 4

6.0 dB target
3.0 dB trigger
2 scanned tones
1 wait count
1 scanned table start index
4 scanned table end index
I will now leave this to run for a minimum of 48 hours uptime before considering any further tuning to any setting, provided instability doesn't start to occur. I'll post results once I have them, fingers crossed.

[Chrysalis]

yeah 19 ES is impossible with 15 CRC, the device is a joke sorry

[Ixel]

yeah 19 ES is impossible with 15 CRC, the device is a joke sorry

Haha yeah, that's probably why ASUS never added ES/SES to the web UI either (as they probably knew it was inaccurate and MediaTek never fixed the inaccuracy).

[Chrysalis]

maybe you think this is great 20 odd ES, then tomorrow you DLM'd for 5000 ES :p

[ejs]

I think the definition of ES does include more than just CRCs:

7.2.1.1.2 Errored second – Line (ES-L)
This parameter is a count of 1-second intervals with one or more CRC-8 anomalies summed over all
received bearer channels, or one or more LOS defects, or one or more SEF defects, or one or more
LPR defects.

Also, I don't think it's possible for the DSLAM to get a different downstream ES count apart from what your modem tells it. These things are measured or counted at the end that's receiving the signal, so for the downstream, that's your modem. If the DSLAM wants to know the downstream ES or CRC count, it has to ask your modem to send it the numbers.

I still think HEC errors are not applicable to PTM - there are no ATM headers present.