Does the DSL "Downstream SNR offset" value only have an effect on some router models or some software versions

Does the DSL "Downstream SNR offset" value only have an effect on some router models or some software versions ?

I am on a long line and its target SNR appears to be 12dB (if I were to keep the router permanently powered on this would probably go down but I prefer to turn it off at night).

I am running OpenWrt 18.06.5 r7897-9d401013fc on a BTHub5a.

Choosing any Downstream SNR offset value between -6 and +6 dB has no effect on the data rate. I was expecting a 10 or 20% speed improvement with a +6dB value (at a cost of poorer line stability).

"dsl_control status" report with Downstream SNR offset of -6dB

ATU-C Vendor ID:                          Infineon 113.200
ATU-C System Vendor ID:                   00,00,30,30,30,30,00,00
Chipset:                                  Lantiq-VRX200
Firmware Version:                         5.8.0.11.1.1
API Version:                              4.17.18.6
XTSE Capabilities:                        0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
Annex:                                    A
Line Mode:                                G.992.1 (ADSL)
Profile:                                  
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 4472 / Far: 4
Errored seconds (ES):                     Near: 119 / Far: 4
Severely Errored Seconds (SES):           Near: 0 / Far: 3
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 2
Unavailable Seconds (UAS):                Near: 211 / Far: 211
Header Error Code Errors (HEC):           Near: 595 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency [Interleave Delay]:               8.0 ms [Interleave]   8.0 ms [Interleave]
Data Rate:                                Down: 2.144 Mb/s / Up: 448 Kb/s
Line Attenuation (LATN):                  Down: 59.4 dB / Up: 31.5 dB
Signal Attenuation (SATN):                Down: 55.6 dB / Up: 31.5 dB
Noise Margin (SNR):                       Down: 11.5 dB / Up: 17.0 dB
Aggregate Transmit Power (ACTATP):        Down: 18.0 dB / Up: 12.6 dB
Max. Attainable Data Rate (ATTNDR):       Down: 2.176 Mb/s / Up: 1.004 Mb/s
Line Uptime Seconds:                      20222
Line Uptime:                              5h 37m 2s

"dsl_control status" report with Downstream SNR offset of +6dB (after doing a full_init)
Slightly slower as it is later in the evening.

ATU-C Vendor ID:                          Infineon 113.200
ATU-C System Vendor ID:                   00,00,30,30,30,30,00,00
Chipset:                                  Lantiq-VRX200
Firmware Version:                         5.8.0.11.1.1
API Version:                              4.17.18.6
XTSE Capabilities:                        0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
Annex:                                    A
Line Mode:                                G.992.1 (ADSL)
Profile:                                  
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 4294962406 / Far: 0
Errored seconds (ES):                     Near: 121 / Far: 4
Severely Errored Seconds (SES):           Near: 0 / Far: 3
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 2
Unavailable Seconds (UAS):                Near: 243 / Far: 243
Header Error Code Errors (HEC):           Near: 1 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency [Interleave Delay]:               4.0 ms [Interleave]   8.0 ms [Interleave]
Data Rate:                                Down: 1.920 Mb/s / Up: 448 Kb/s
Line Attenuation (LATN):                  Down: 59.3 dB / Up: 31.5 dB
Signal Attenuation (SATN):                Down: 55.5 dB / Up: 31.5 dB
Noise Margin (SNR):                       Down: 13.5 dB / Up: 17.0 dB
Aggregate Transmit Power (ACTATP):        Down: 17.6 dB / Up: 12.5 dB
Max. Attainable Data Rate (ATTNDR):       Down: 2.048 Mb/s / Up: 984 Kb/s
Line Uptime Seconds:                      987
Line Uptime:                              16m 27s

HomeHub 5 uses Lantiq VRX208 as the xDSL modem, and it's well supported in OpenWrt. Your problem is your DSL line.

You need to know that ISP is the one who decides the SNR range the modem is allowed to sync to. There's absolutely nothing you can do to lower the SNR if DSLAM is configured with 12 dB as the lower limit.

The same goes for the upper limit (but it would be weird if any ISP did that). There are also other limits (min. DS/US bandwidth, for example) that might cause your modem to "ignore" DS offset.

tl;dr: Your line parameters are very bad, so you're probably hitting the limits configured by ISP when you tweak SNR offset too much.

Yes, I am on a very long line (about 6.5 Km long I think). I am probably close to the length limit of ADSL.

It sounds like I misunderstood what the SNR offset does. I thought, for example, a +6 value would report to the DSLAM that the SNR was 12dB when it was actually 6dB and therefore the line would sync at a slightly higher speed.

Is there a definition somewhere of what the downstream SNR offset value actually does ?

That's bordering on the impossible, so they probably set a high SNR limit to minimize the instability as much as they can.

You can't fake it - DSL sync requires cooperation on both sides, there's no way to fake SNR since it's a value measured on both sides independently. There might even be a difference in measurements on CPE and DSLAM, depending on the hardware (source: I worked for an ISP).

You use SNR offset to tweak the synced bandwidth when conditions on the line allow for some headroom.
Example 1: Recently, my ISP set me a profile with 6 dB target margin and a lot of overhead. I added +2 dB in the offset to get 8 dB SNR and a more stable line with minimal loss in the bandwidth.

Example 2: ISP sets the target margin to 8 dB, but your contract and DSLAM profile configuration allows higher speeds. In this case, if you're willing to sacrifice the stability, you'd configure -2 dB offset, lowering the margin to 6 dB and getting a few Mbps more (in case of VDSL).

1 Like

But it is the modem that measures and reports back the Downstream SNR, the DSLAM really can not measure that on its own, so the DSLAM is going to believe the CPE here...
In the end you are right and one trades stability versus bandwidth, but depending in the usecase that might be okay.
@gc1 I beieve that different dsl-blob interpret the actual val ue differently 9at least that is reported for fritzbox modems with AVM's proprietary firmware) so it might be that the value in the GUI simply is not correct (and some values might not even be supported by your dsl-blob at all. So if you want to go that route you probably should try out a few different vaules (make sure to test each one long enough so that your are reasonably confident you hace a feeling for the current stability/speed tradeoff).

That's true for downstream, my mistake. But my point still stands, even if one managed to mess with the xDSL blob to make it report fake values, I'm not sure how the math and physics would play with that fake data. The most possible outcome is, if the profile is configured for a minimum SNR of 12 dB, that the sync would fail - if nothing else, DSLAM would aim for 12 dB, which would actually mean 18 dB with 6 dB offset, which is cleary impossible on this line.

1 Like

I think how this works is that this value affect what the modem returns to the DSLAM, so the DSLAM tells the Modem, aim for X dB, this value will tell the Modem to actually aim for X-offset, the DSLAM really will not know. Whether that is a good idea is a different kettle of fish however, often ISPs set these values for a reason so going below that value risks instability.

Actually, I was talking about a hypothetical scenario here, where the modem would report fake values.

The native way, and the same thing that can be configured in Fritz!OS (Maximum stability/Maximum performance) is that the modem actually tries to sync to the defined SNR, without lying to the DSLAM. DSLAM can either accept it or not, depending on the profile configuration. (As I said, it requires consent on both sides - both DSLAM and CPE have to agree on the line parameters to keep the link alive.)

Thank you everyone for your answers.

I tried a few smaller downstream SNR offset values such as ±2 and ±3 and there was also no effect for my router+line. So it looks like end users should consider this value to be a hint rather than having a definite effect for the various reasons you have explained.

Hello, reporting in as a user of a Netgear DM200, of which uses a Lantiq chipset as well;
I've had the same issue with the SNR offset tweak not working, but I've noticed this only seems to be an issue when using ADSL1 (G.DMT) modulation, as the tweak works flawlessly if the DSLAM/Modem requests ADSL2/ADSL2+.

This leads me to believe it's either a hardware limit in the Lantiq modems or a firmware bug when using ADSL1 with the value since as far as I know, only one firmware command in the actual firmware blob (accessed with VDSL_CPE_Control) adjusts downstream SNR. There is unfortunately not much one can do about that.

I'm using a BT HH5 (Business Hub) on PlusNet and have the same problems re tweaking the SNR margin. Changes to the OpenWrt (19.07) config make no difference to the reported margin or speed.
I was using a Billion 7800N a while back on the same line and that did have an effect when changing the SNR margin.