Kitz Forum

Broadband Related => FTTC and FTTP Issues => Topic started by: Ornum on February 15, 2018, 12:03:33 PM

Title: Speed capping to reduce errors
Post by: Ornum on February 15, 2018, 12:03:33 PM
I'd like to try the advice given here http://forum.kitz.co.uk/index.php/topic,16427.0.html but have no idea how or if it's possible for my hardware. I have a TP-Link W9980 with LEDE installed. Does anyone have any idea how to go about capping my sync rate with this setup?

Cheers!
Title: Re: Speed capping to reduce errors
Post by: j0hn on February 15, 2018, 02:09:57 PM
You can't I don't think. Needs to be a Broadcom based modem. Any TP-Link that is Broadcom, they block access to the necessary CLI commands.
Title: Re: Speed capping to reduce errors
Post by: Ornum on February 20, 2018, 03:44:37 PM
Any idea if I can do it with the BT Home Hub 5 or the router that Plusnet provides?
Title: Re: Speed capping to reduce errors
Post by: j0hn on February 20, 2018, 04:30:46 PM
Pretty much these models (http://dslstats.me.uk/routers.html).
Needs to be Broadcom with access to the CLI.
I don't think any ISP supplied modem allows this.

Some Lantiq modems let you adjust the snrm I believe which you might be able to accomplish the same thing with but you would need advice from others if going down that route.
It wouldn't be a sync cap as such but aiming for a high snrm would lower the sync as a result. A bit more hit & miss.
Same applies that no ISP modem will allow this.
Title: Re: Speed capping to reduce errors
Post by: Ixel on February 20, 2018, 07:11:15 PM
Pretty much these models (http://dslstats.me.uk/routers.html).
Needs to be Broadcom with access to the CLI.
I don't think any ISP supplied modem allows this.

Some Lantiq modems let you adjust the snrm I believe which you might be able to accomplish the same thing with but you would need advice from others if going down that route.
It wouldn't be a sync cap as such but aiming for a high snrm would lower the sync as a result. A bit more hit & miss.
Same applies that no ISP modem will allow this.

DrayTek Vigor devices, such as the 2860, do this. They allow you to adjust the SNRM target as an offset between -5 dB to +5 dB via the CLI.
Title: Re: Speed capping to reduce errors
Post by: ejs on February 20, 2018, 07:40:17 PM
And of course running LEDE, the 9980 will have access to the full Lantiq CLI, with the same +/- 5 dB SNRM adjustment.

For example, for +2 dB, I think it is:
Code: [Select]
dsl_cpe_pipe locs 0 20If the firmware doesn't have the dsl_cpe_pipe executable, you'll have to refer to the DSL scripts within the firmware to see how they do things.

It may be possible to actually cap the rate using the Lantiq CLI, however this would require using "dsl_cpe_pipe dms ..." and working out a lot of hexadecimal to specify the content of the CMD_BearerCh0_DS_Set structure, which should be possible with reference to the source code.
Title: Re: Speed capping to reduce errors
Post by: NewtronStar on February 20, 2018, 09:09:00 PM
Surly there is no way to adjust the SNRM via EU's equipment on FTTC it must be just a sync cap you lower the sync the SNRM goes up you then increase the sync the SNRM goes down.
Title: Re: Speed capping to reduce errors
Post by: Ixel on February 20, 2018, 09:11:31 PM
Surly there is no way to adjust the SNRM via EU's equipment on FTTC it must be just a sync cap you lower the sync the SNRM goes up you then increase the sync the SNRM goes down.

Nope, the SNRM target offset setting for FTTC/VDSL2 works on DrayTek Vigor's, at least the 2860Vac when I tried it. You can adjust the offset by -5 to +5 dB in increments of 0.1 dB. As long as the maximum sync rate isn't already met, you can reduce the target SNRM below the setting on the DSLAM for the downstream.
Title: Re: Speed capping to reduce errors
Post by: NewtronStar on February 20, 2018, 09:21:49 PM
Ok so why is the maximum set to +5dB can you set your SNRM above 6dB  to say 7 or 9 dB  or 3dB and 4dB
Title: Re: Speed capping to reduce errors
Post by: ejs on February 20, 2018, 09:27:48 PM
If the target SNRM from the DSLAM is 6 dB, and you add 5 dB, you should end up connecting with a SNRM of 11 dB.
Title: Re: Speed capping to reduce errors
Post by: NewtronStar on February 20, 2018, 09:34:39 PM
If the target SNRM from the DSLAM is 6 dB, and you add 5 dB, you should end up connecting with a SNRM of 11 dB.

That would be the same if I capped my sync of 40Mbps to 20Mbps the result is 11dB but XdB has me on 4dB and that you cannot change unless the DLM sees issues.
Title: Re: Speed capping to reduce errors
Post by: Ixel on February 20, 2018, 10:11:24 PM
That would be the same if I capped my sync of 40Mbps to 20Mbps the result is 11dB but XdB has me on 4dB and that you cannot change unless the DLM sees issues.

Unless you're at the maximum sync rate already, you can make this -1 dB on the DrayTek (vdsl snr -10 if I recall correctly) which will reduce your target SNRM to 3 dB in the above scenario. The setting on the DrayTek is an offset, not an absolute value. If I had an SNRM target of 6 dB and I wanted it to be 3 dB then I would do something like 'vdsl snr -30' (without quotes).
Title: Re: Speed capping to reduce errors
Post by: NewtronStar on February 20, 2018, 10:30:03 PM
SO just get a DrayTek and set the SNR to -30 to get a target margin of 3dB on FTTC if only it was that simple why wait for XdB just get one of these modems
Title: Re: Speed capping to reduce errors
Post by: GaryW on February 21, 2018, 08:32:47 AM
Based on my (limited) experience, I'm not sure it's quite that simple...

I have a Billion 8900AX-2400, which syncs at a (banded) 14999 DS.  The SNRM at first sync is around 8dB if I sync in daylight or 6.5dB if I sync at night - drifting down over time to around 6.5dB during daylight hours and 4.5dB at its lowest over night.

I briefly tried a Draytek 2760, at a point when I knew from my Billion that I was banded at 14999.  Without tweaking the SNRM offset on the Draytek, it synced at 11400 (ish, can't remember exactly) - I know that looks like a banded limit, but I immediately switched back to the Billion and was straight back to 14999.  Based on memory (I don't have detailed stats that far back), when my line had been banded at 11400 in the past the SNRM when my Billion first synced was in the region of 12dB.  I just gave up on the Draytek (sent it back) without really looking at stats or playing with parameters - didn't seem worth it since the starting point was so poor - but my guess would be that if I'd played with the SNRM offset it may have got me back towards the 14999 that the Billion achieves without any tweaking.  i.e. no gain.

Has anybody tried back-to-back tests between a decent Broadcom modem and a Draytek to see what really happens?  I don't doubt that playing with the SNRM offset improves the sync on the Draytek, but what would the sync have been if a Broadcom-based modem had been used w/o any tweaking?
Title: Re: Speed capping to reduce errors
Post by: Ixel on February 21, 2018, 08:53:00 AM
Based on my (limited) experience, I'm not sure it's quite that simple...

I have a Billion 8900AX-2400, which syncs at a (banded) 14999 DS.  The SNRM at first sync is around 8dB if I sync in daylight or 6.5dB if I sync at night - drifting down over time to around 6.5dB during daylight hours and 4.5dB at its lowest over night.

I briefly tried a Draytek 2760, at a point when I knew from my Billion that I was banded at 14999.  Without tweaking the SNRM offset on the Draytek, it synced at 11400 (ish, can't remember exactly) - I know that looks like a banded limit, but I immediately switched back to the Billion and was straight back to 14999.  Based on memory (I don't have detailed stats that far back), when my line had been banded at 11400 in the past the SNRM when my Billion first synced was in the region of 12dB.  I just gave up on the Draytek (sent it back) without really looking at stats or playing with parameters - didn't seem worth it since the starting point was so poor - but my guess would be that if I'd played with the SNRM offset it may have got me back towards the 14999 that the Billion achieves without any tweaking.  i.e. no gain.

Has anybody tried back-to-back tests between a decent Broadcom modem and a Draytek to see what really happens?  I don't doubt that playing with the SNRM offset improves the sync on the Draytek, but what would the sync have been if a Broadcom-based modem had been used w/o any tweaking?

I'm pretty sure the reason why the DrayTek syncs lower, if you're on fastpath that is, is because it applies reed solomon coding (R: 16) on the downstream where as a modem with a Broadcom chipset doesn't seem to (R: 0). As such the 'R: 16' reduces the sync rate as there's a light amount of error correction. I imagine all devices with a Lantiq do this for some reason.

I've used both Zyxel/HG612 and DrayTek Vigor 2860Vac and of course the HG612/Zyxel can get a higher sync as they have a Broadcom chipset where the DrayTek Vigor 2860Vac has a Lantiq chipset. I've played with the SNRM offset on the DrayTek and it can allow for a higher sync rate if you reduce it, provided the maximum sync rate isn't already achieved.
Title: Re: Speed capping to reduce errors
Post by: GaryW on February 21, 2018, 08:59:56 AM
I'm not on fastpath - I'm interleaved (31 data bytes, 10 redundancy bytes according to the Billion, not sure what the Draytek was doing).
Title: Re: Speed capping to reduce errors
Post by: Ixel on February 21, 2018, 09:05:49 AM
I'm not on fastpath - I'm interleaved (31 data bytes, 10 redundancy bytes according to the Billion, not sure what the Draytek was doing).

Hmm, I see, interesting. I've never really compared the results when I've been interleaved but perhaps it still applies something differently that causes some additional overhead or something.
Title: Re: Speed capping to reduce errors
Post by: j0hn on February 21, 2018, 09:11:54 AM
Quote
I briefly tried a Draytek 2760, at a point when I knew from my Billion that I was banded at 14999.  Without tweaking the SNRM offset on the Draytek, it synced at 11400 (ish, can't remember exactly) - I know that looks like a banded limit, but I immediately switched back to the Billion and was straight back to 14999.
Banding can change on the fly when your swapping modems back and forth.
I'll eat Paddys hat if the Draytek didn't hit a banded figure. Probably over 5000 to 1 odds it resynced at that exact number (11,399 you've stated on numerous previous posts).
Quote
I just gave up on the Draytek (sent it back) without really looking at stats or playing with parameters - didn't seem worth it since the starting point was so poor

14,999 @8dB snrm would be 19-20Mb attainabnle
11,399 not banded (6dB) would be under 60% the sync rate of the Billion.
The Broadcom chipsets do tend to perform better/sync higher than Lantiq.
I don't believe the difference to be anywhere near that high though.
Title: Re: Speed capping to reduce errors
Post by: GaryW on February 21, 2018, 09:33:33 AM
Banding can change on the fly when your swapping modems back and forth.
I'll eat Paddys hat if the Draytek didn't hit a banded figure. Probably over 5000 to 1 odds it resynced at that exact number (11,399 you've stated on numerous previous posts).
14,999 @8dB snrm would be 19-20Mb attainabnle
11,399 not banded (6dB) would be under 60% the sync rate of the Billion.
The Broadcom chipsets do tend to perform better/sync higher than Lantiq.
I don't believe the difference to be anywhere near that high though.

Does banding really change on the fly that quickly?  There was one resync to put the Draytek in place, then another resync later in the day to put the Billion back in place.  Would DLM really drop the banding to 11.4 and then restore it to 15 in the same day?  Based on my previous experience of my line (when I'd eliminated internal RFI), it took somewhere in excess of a month for DLM to raise my banding from 11.4 to 13, and a further month to raise it from 13 to 15.  It seems odd that DLM would then drop the banding to 11.4 on a resync then raise it to 15 on the next resync later in the day.  Or are you saying that DLM remembers/varies banding for a particular chipset?
Title: Re: Speed capping to reduce errors
Post by: j0hn on February 21, 2018, 10:04:29 AM
Quote
Does banding really change on the fly that quickly?
Yes it can.
DLM reacts to ES over a 24 hour period, once a day.
It doesn't wait 24 hours with resyncs.
It can react instantly to multiple resyncs (e.g swapping modems).

I've seen (on numerous occasions) problem lines constantly resyncing back and forth between banded levels throughout the day.

My main point is that the DrayTek doesn't sync anywhere near that low in comparison to Broadcom chipsets (under 60%).
The odds that it wasn't a banded level are extremely high.

Title: Re: Speed capping to reduce errors
Post by: ejs on February 21, 2018, 07:36:28 PM
I'm pretty sure the reason why the DrayTek syncs lower, if you're on fastpath that is, is because it applies reed solomon coding (R: 16) on the downstream where as a modem with a Broadcom chipset doesn't seem to (R: 0). As such the 'R: 16' reduces the sync rate as there's a light amount of error correction. I imagine all devices with a Lantiq do this for some reason.

It's never quite that simple unfortunately. Remember that the modem works out the best speed it can manage subject to meeting the bit error rate (generally 1 bit error in 107 bits). When you add error correction, that reduces the error rate, and so should allow for more speed meeting the same bit error rate.
Title: Re: Speed capping to reduce errors
Post by: Ixel on February 21, 2018, 07:43:40 PM
It's never quite that simple unfortunately. Remember that the modem works out the best speed it can manage subject to meeting the bit error rate (generally 1 bit error in 107 bits). When you add error correction, that reduces the error rate, and so should allow for more speed meeting the same bit error rate.

True, but I would still imagine it's at least part of the reason :).
Title: Re: Speed capping to reduce errors
Post by: kayjay on October 26, 2018, 06:52:25 PM
On the Draytek increasing the margin does indeed work and I sync up at lower speeds with a higher margin, but it does not solve the problem. As soon as my SNR degrades, and it does at some times of the day, the line still drops as before. What I really want is to to fix the sync speed to a lower value such that when the SNR is poor the standard 6db noise margin is not exceeded and the line does not drop. This issue can happen 20+ times a day