Capped upload speed on 21CN

[#1]

By default Plusnet cap the upload speed to 448. The reason given is that uncapping can decrease the download speed. The upload can be uncapped upon request. However I've never seen a post from anyone giving details of the before/after download speed to prove this theory.
There is a totally separate option to have significantly faster upload, Annex M which does steal frequencies from download:
[quote=http://en.wikipedia.org/wiki/ITU_G.992.5_Annex_M]Annex M is an optional specification in ITU-T recommendations G.992.3 (ADSL2) and G.992.5 (ADSL2+), also referred to as ADSL2 M and ADSL2+ M. This specification extends the capability of commonly deployed Annex A by more than doubling the number of upstream bits. The data rates can be as high as 12 or 24 Mbit/s downstream and 3 Mbit/s upstream depending on the distance from the DSLAM to the customer's premises.
The main difference between this specification and Annex A is that the upstream/downstream frequency split has been shifted from 138 kHz up to 276 kHz (as in Annex J), allowing upstream bandwidth to be increased from 1.4 Mbit/s to 3.3 Mbit/s, with a corresponding decrease in download bandwidth.
I'm wondering if there is confusion about the download being reduced because that is what happens on Annex M, on Annex A there is no reallocation of frequencies when the upload is uncapped.
Has anyone actually seen a reduction in download speed when their upload was uncapped?

[#2]

Cant say I have noticed, Although I got my upload uncapped pretty much straight away.
DownStream Connection Speed 21116 kbps
UpStream Connection Speed 1225 kbps

[#3]

I queried this before on the forums as uncapping the upload speed should have no affect on the download. I believe in the FAQ PN only mention stability issues when uncapping and I wondered how they came to this conclusion if the majority of connections by default are capped.

[#4]

Aren't the upload frequencies at the low end? If that is the case isn't it more likely that downstream problems are more likely to cause instability?
Edit: I'd like to see a bits/tone graph before and after uncapping.

[#5]

Did you think about it and thought may be if each bin is pushed to the limit then perhaps stability could be an issue. I know that my immediate reaction was lower frequency are used so stability should not be an issue and if so the DLM should sort it. But is the DLM as active on the upstream as it is on the downstream?

[#6]

I didn't think it was - and we normally see higher noise margins on the upstream anyway.

[#7]

On my uncapped upstream it's 6dB with a sync of 900kbps.

[#8]

Plusnet posted the following explanation for initially capping the upload speed at 448kbps

Quote from: Ben

We supply ADSL2+ with a 448kbps due to the significantly lower fault rate. We can uncap your upload without issue, just raise a ticket.

[#9]

OK - next question.
Can anyone post details of faults they have encountered as a result of asking for their upstream to be uncapped?

[#10]

Quote from: spraxyt

Plusnet posted the following explanation for initially capping the upload speed at 448kbps Quote from: Ben We supply ADSL2+ with a 448kbps due to the significantly lower fault rate. We can uncap your upload without issue, just raise a ticket.

But as I pointed out before on another thread how have PN come up with that conclusion when all conversions are capped by default and from the original trial I can't recall having uncapped upstream was a problem.
I believe that by default BT uncapped the upstream, at least they do for Openreach employees who as like all BT employees get their BB free.

[#11]

The conclusion was reached during the ADSL2 trials with PUG members and probably others.

[#12]

HI guys,
I've just been talking to Dave about this. He explains that if we maxed out both the upstream and downstream it was more likely that instability could occur. As to it affecting the downstream rate we saw that downstream rates were compromised when there were significant errors on the upstream, so, on the whole it seemed more sensible to provision all with capped upstream with the option to uncap if requested. My own personal opinion is that the majority of users never need greater upstream speed and with that in mind it was probably a sensible decision for the business to reduce unnecessary fault reports. It would be different if we didn't allow uncapping by request but as we do I don't think it's a big deal to request it if you want it.
Jojo

[#13]

That makes more sense I think. It's not that the downstream sync speed is reduced by uncapping the upstream but that due to errors on the upstream (e.g. the ACKs) the downstream throughput is affected because there will be more retries.
Going on from that when someone asks about uncapping the first question should be how many upstream errors is your router logging at present. If it's significant uncapping may be inadvisable.

[#14]

Quote from: jelv

Going on from that when someone asks about uncapping the first question should be how many upstream errors is your router logging at present. If it's significant uncapping may be inadvisable.

Makes sense

[#15]

Quote from: Joanne

I've just been talking to Dave about this. He explains that if we maxed out both the upstream and downstream it was more likely that instability could occur. As to it affecting the downstream rate we saw that downstream rates were compromised when there were significant errors on the upstream, so, on the whole it seemed more sensible to provision all with capped upstream with the option to uncap if requested.

Is this supposition on Dave's part or hard facts from the trial? It can't be from the trial as this was not run to test this but was more a suck and see. To support this supposition then the original trial should have been conducted using one of two methods.
Method One
2 random equal populations are selected. One population to be capped the other not capped. Then monitor reported connection faults.
Method Two
Place everyone on a capped speed for x number of weeks then uncap them and monitor for an increase in reported faults.
These methods would back up the supposition but what we don't know if the conclusion was reached on a few connections that had underlying problems.
All what I can say looking at my uncapped and currently very unstable connection (21+ disconnects today) that I see very few upstream errors 0 FEC 7 CRC but downstream errors are in the 10,000's.