What determines upstream speed?

[#1]

I think part of the issue is that the DLM is all too keen to apply interleaving (and by implication FEC) when essential and quite reluctant to back it off after sustained stability at the higher SNRM / lower speed.

Once applied it sticks like superglue.

[#2]

---

@EnglishMohican wrote:

Kitz seems to support you, at least in part.

Forward Error Correction does reduce the amount of useful data that can be transmitted because it involves transmitting extra bytes of error correction data that are not normally transmitted if FEC is not applied. That is news to me as we are usually told to ignore FEC errors as they cost us nothing. If you and Kitz are correct then they clearly do cost us throughput.

The FEC data is always sent, the cost is the same regardless of the number of FEC errors, that's why the number of FEC errors does not really matter.

I am less happy with your statement that the bytes used for FEC are not included in that difference but instead reduce the DSL bandwidth in some artificial way. The implication is that the bandwidth is still physically 988kbps (or whatever) but that only 888kbps is reported because 100kbps is used for FEC (my numbers here are illustrative, not actual). Also, if the physical figure is still 988kbps, then why would the SNR increase. I cannot believe that the modem would artificially increase the SNR to match the artificial decrease in bandwidth.

---

Why are you less happy with this implication? It's completely correct. The more technical term for the "sync speed" is actual net data rate. Modems do not display a "gross data rate" including the amount of bandwidth being used by FEC data. It's "net" like net pay, the FEC tax has already been deducted.

The upstream SNRM may well have been increased by the coding gain introduced by the FEC+interleaving. SNRM is defined relative to the error rate. SNRM is defined as the maximum increase in noise power for which the modem can maintain the bit error rate. So the error correction capabilities of the FEC+interleaving reduce the error rate, or could allow more bandwidth at the same error rate, or with the bandwidth hitting other limitations, it'll increase the SNRM.

[#3]

---

@ejs wrote:

---

The FEC data is always sent, the cost is the same regardless of the number of FEC errors, that's why the number of FEC errors does not really matter.

So the error correction capabilities of the FEC+interleaving reduce the error rate, or could allow more bandwidth at the same error rate, or with the bandwidth hitting other limitations, it'll increase the SNRM.

---

1)  If I have zero FEC errors (or very few), then the cost of sending the FEC correction data is being paid for no benefit. It could be turned off and not sent. So whether I have 1 million or 2 million FEC errors may not matter, it is worthwhile in either case but whether I have 10 errors or 1 million does. In the first case, turn FEC off and stop paying the cost of using it all the time for very little cost in retransmissions.

2) You have just said the crucial thing - "hitting other limitations, it will increase the SNRM". So in this case it has increased the SNRM - so what are the other limitations???? Can I remove those (or can Plusnet) and then I can have a larger bandwidth.

[#4]

You could equally argue that if you don't have a need to make a car insurance claim you are paying car insurance for no benefit. FEC maintains stability for those occasions where there are errors.

[#5]

@EnglishMohican There appears to be some misunderstanding of just how basic ADSL (and later faster variants) work to deliver an effective Broadband service along a piece of copper wire.  It's a clever use of technology to maximise delivery across a wide variety of installed cable and yes, it sometimes ain't perfect for individual users!

Take a look at this info to get an insight.  @ejs @Townman and Kitz are all basically saying the same thing and just use differing ways of simplifying the explanation.

So simplified:

FEC is a method of 'in flight' error correction and is an integral, non optional component of the protocol.

Interleaving: Is an 'option' to mitigate the effect of some forms of 'noise' on the line.

In your case it looks like some of the 'bins' in the frequency range used for upstream bandwidth are most susceptible to noise.  Finding and fixing the source of the noise should improve the data rate.  But it may not be easy, particularly if the rate is within the BT accepteable range for your line.

[#6]

@Townman

Yep - If I could be absolutely certain I was not going to have a car accident and need to make a claim, then I would argue that car insurance is a waste of money - as it would be. Ignoring legalities, the truth is that I can never be absolutely certain and the costs of trying to recompense a seriously injured child in a car accident are far beyond my means without the help of an insurance company.

FEC insurance is not really in the same class. The purchase cost in lost bandwidth appears to be quite significant (8%) and the "costs" removed by a "correcting errors" claim can be very limited -  not in the injured child class under any circumstances.

Presumably, those who have 80Mbps fibre connections can afford to lose 8% without noticing a deterioration in their iptv viewing but when ones bandwidth is marginal it may be better to be just about able to watch tv for 6 days and then have a disastrous 7th day rather than not be able to get enough bytes to watch it at all.

So I think you could be very right earlier when you argued for a more adaptive error correction strategy. Let the DLM turn FEC on when there are lots of errors and turn it off again when there are few or none.

I would prefer something a little more nuanced than the experiment we are going to try in a day or two when my error correction gets turned off totally but we will see. I may be back begging for it to be turned back on!

Moderator's note by Mike (Mav): Post released from Spam Filter

[#7]

---

@EnglishMohican wrote:

 2) You have just said the crucial thing - "hitting other limitations, it will increase the SNRM". So in this case it has increased the SNRM - so what are the other limitations???? Can I remove those (or can Plusnet) and then I can have a larger bandwidth.

---

It's what I mentioned earlier, limitations of the upstream framing parameters and the maximum delay and minimum INP value. Sorry I can't really give a better explanation because I don't understand it very well myself. There is table K.3b in the ITU-T G.992.3 document which does give some bandwidth limits imposed by different combinations of delay_max and INP_min, although it does list 832k for the typical upstream INP_min=2 and delay_max=8, so the assumptions given in the document above the table probably aren't correct for what BT use on our ADSL.

The INP_min and delay_max values control the FEC and interleaving, so by switching off FEC+interleaving, you'll setting them to INP_min=0 and delay_max=whatever value means lowest delay, 1 apparently.

[#8]

@MauriceC Thank you for your interest.

I note that you state that FEC correction is not optional and cannot be turned off. That differs from what @ejs, Kitz and @Gandalf appear to be saying as they seem to say it is optional (Gandalf says he has asked that it be turned off along with interleaving). I am not saying you are incorrect - simply trying to highlight the inconsistencies in the answers I get. Getting to the bottom of those inconsistencies and either removing them as false information or understanding why the apple falls might improve mankind's knowledge - or at least improve my upstream speed.

I may have been sloppy in my wording in an earlier post. If I used SNR when I should have used SNRM I apologise but it is SNR margin that is high (12 to 13db) on my upstream. This implies that more bits could be successfully crammed into the existing bins without increasing the errors significantly. That would give me more bandwidth. So we are back to @ejs's "other limitations" which I hope he has explained in the post that came in as I typed this:)

[#9]

@ejs, Thank you for that reference. I will see if I can find a copy and whether it makes any sense to me. It may require a lifetime of study to decode it

[#10]

---

@EnglishMohican wrote:

Presumably, those who have 80Mbps fibre connections can afford to lose 8% without noticing a deterioration in their iptv viewing but when ones bandwidth is marginal it may be better to be just about able to watch tv for 6 days and then have a disastrous 7th day rather than not be able to get enough bytes to watch it at all.

---

You have assumed that FEC causes a net loss of bandwidth. This is not necessarily the case. I get more bandwidth, as in, my modem attains a higher downstream net data rate (sync speed) with FEC+interleaving than without.

[#11]

After 4 hours of reading G992.3 my brain hurts.

When I wrote that about iptv, I neglected some of the provisos as I was following Townman's comments about car insurance and an implication of occasional accidents and insurance claims

I totally accept that if your line suffers short impulse noise fairly regularly, so you get lots of errors that can be corrected by the FEC system then having FEC+interleaving will be a huge advantage as the cost (in terms of extra data downloaded) will be far outweighed by the benefit in terms of reduced need to download re-transmitted data. This seems to be your situation.

At present I am sticking to the idea that if there are not many errors for FEC to correct then it is more effective to turn it off. In some ways, that is the reasoning behind G.IMP,  that is, it's better to download the data again when needed than to routinely download error correction data that is not needed much of the time. Admittedly, G.IMP re-downloads the data more efficiently than I can.

[#12]

Reporting back as promised.

Its a bit early really as everything could go belly up but so far so good.

The internet went down briefly on Tuesday morning and when it came back up the base latency had dropped from about 30ms to about 10ms and the latency as measured by Thinkbroadband (so under load) has dropped from 67ms to 50ms.

Upstream sync rate has gone from 888 to 1171 - which simplistically is a 30% improvement. On the downside, my downstream speed is lower than it was (5283 vs 5600) but that might simply be that it reconnected in the middle of the night so maybe not the best moment to negotiate a rate. (The downstream SNR is slightly high by previous standards)

The crucial bit is how many errors do I get and that is the difficult bit to answer. Previously, I got a small number of FEC errors upstream and slightly more down. Now I get none - but that is because the system can no longer identify FEC errors.

I now have some software monitoring many of the modem's error related counts - but I do not have a decent previous history  to compare it against and am not even sure of the significance of some of the numbers. However, error seconds seem very comparable, 1 or 2 every so often, HEC count has reduced - but that is downstream, upstream figures are not available and code violations are up both up and down but not by much.

In use terms I think things are slightly better, Thinkbroadband report a much better single thread speed but not much change on the multithread test (both downstream) and upload speed has gone from around 450 to 700 kbps - but time will tell whether this sticks.

I am going to consider this problem fixed but will continue to monitor things and may be back. Thank you to all who contributed.