Disable or filter high frequency VDSL2 bands?

g67575

g67575

g67575

Soldato
Joined
30 Jun 2019
Posts
8,159
I've found that on my relatively long FTTC line, the D3 frequency band (higher frequencies) are much more error prone. I'm reasonably sure about this, since setting an SNR Margin of 12dB prevents frequencies over approx. 14mhz from being received by the VDSL2 modem. As a result, the CRC errors reported have dropped by about 10 times (9 CRCs, 14 hours since line sync).

But, it would be much better to be able to disable the D3 band together, for stability.

Unfortunately, BT's equipment does not allow lower line profiles than 17a to be selected by customers, these line profiles use fewer frequency bands and only use frequencies upto ~12mhz / 8mhz.

So, is there any way to block/ avoid using higher frequencies on VDSL2?
 
Last edited:
okay, I worked it out :)

Fortunately for me, it can be done through software, with an Asus DSL-N16 router / modem.

First, I downloaded Putty, then I enabled SSH on my router web interface and logged in to ssh (I'm new to this).

Then, typed in:
wan vdsl2 set ds_tone 0 2560

I had to resync the line to apply this change.

To undo this, I can type:
wan vdsl2 set ds_tone 0 0

The first number is the minimum tone and the 2nd number is the max tone (channel), and the same thing is possible for the upstream bands. You can see a confirmation message in the router log too.

(these numbers are channels, not the frequency, which confused me slightly, so I experimented)

I don't know yet if these changes survive a reboot or resync. Here are the results (SNR margin at default now):

6-DB-D3-band-off.jpg
 
Last edited:
Has anyone else tried this? My initial impression (after being synced for 15 hours) is that the line appears to be very stable (Downstream or Upstream 0 CRC errors).

My line has recently had some interleaving applied to it, but I believe this is unrelated (probably as a result of the CRC errors before I made this change). The interleaving doesn't bother me, I don't know why BT / Openreach don't just apply it to all lines by default for FTTC lines, as the increase in connection latency isn't that much.
 
Last edited:
I'd forgotten set ds_tone was even possible - I generally found after awhile the line settled to the best balance of speed and stability with a bit of SNR tweaking in the longer run anyhow.
 
Yeah, I tried setting the SNR Margin at 12dB before, but I think my brothers noticed the throughput was lower (about 10-15mbps), when downloading files :). Also, there were still a few CRCs on the line.

This seems like a more elegant solution in my case, I can increase the SNR Margin a bit again, if the CRC errors ever increase by a large amount. Or, I could force on interleaving at the max amount (presumably there is an SSH command for this), which might be preferable.

My line is now synced at 39019 kbps, but hopefully, it will soon sync at or near the estimated 'Max Rate' of 55104 kbps. Removing the higher frequency D3 band has barely had any impact on the total throughput, it seems.
 
Last edited:
Depends on the device - there is usually a command to commit the the changes or on some devices you can alter a startup script to include them.

From a quick Google on their own these command line tweaks don't normally survive a reboot but do a resync.
 
Good to know, thanks. I suppose ill just avoid rebooting the router then, I can try a resync later once I've finished checking if it can go a whole day without CRC errors.
 
The interleaving seems to be doing a lot of work on my line:
near-end FEC error interleaved: 7771
far-end FEC error interleaved: 7

All other error counters = 0

Edit - on second thought, I think all the FECs are reported as interleaved by my router, so it's hard to tell what affect the interleaving may be having.
 
Just an update on this for anyone interested in how well it's working, with the D3 Band disabled.

The Downstream is rock solid (0 CRC errors in a couple of days), as you might expect. The Upstream is still very good, with just 2-4 CRCs per day so far.

I could reduce the upstream VDSL2 frequencies (tones) too, maybe I will if the line sync profile does not improve within a week or so.

As I understand it, the DLM counts CRCs (more precisely, errored seconds), for the downstream and upstream separately, so a few CRCs on the upstream may not matter much (because high CRCs on the upstream shouldn't affect how limits / banding is applied to the downstream).
 
Last edited:
So, my router has completely rebooted today for some reason, and has synced at a much higher rate (with the D3 band re-enabled automatically):


resync.jpg


I am fairly sure that the interleaving applied to the line (at almost of the maximum amount of 3072 on the downstream), is what has made the difference to the line stability. It has been synced at this speed for 13 hours, with 0 CRCs.

I will keep it like this for now, as long as the CRC errors don't increase a large amount (which would likely lead to a DLM sync rate cap within days / weeks anyway).

What's odd is the DLM seems to have forced my router to reboot itself entirely, I thought it would just do a resync on the line. Also, the SNR Margin is now at 5dB.
 
Last edited:
So, does anyone else run their connection this way? As in, do you disable the D3 band on your VDSL2 connection, to reduce line errors?

As far as I know, most routers (apart from Asus) lack the ability to set which VDSL bands are used...
 
You must log in or register to reply here.
Back
Top Bottom