I think you put that very well but come to the wrong conclusion. You effectively contradict yourself in your final sentence. Why it happens has not been put to bed.

My only statement is that it isn't the Current line speed itself causing the problem. If they used the IP Profile itself in their system the problem would still be there.

It could very well be a systemic problem in the interaction between that and the traffic prioritisation system when passing data through at such speeds. Or it could simply be that the buffering system that is used to hold the speed down to the required value is old and under-powered.

Do we even know it isn't caused in the BT Wholesale cloud? We need some IDNet, Zen, AAISP results. Infinity may not be reliable for this purpose as I believe it's handled differently within BTW.

In reply to a post by RobertoS:

I think you put that very well but come to the wrong conclusion. You effectively contradict yourself in your final sentence. Why it happens has not been put to bed.

Isn't that exactly what I said? "The question about why it happens has not."

Confused... but to be clear: We haven't been given any explanation, so currently have little idea why this happens. We haven't even really had it acknowledged as a valid thing for them to investigate.

_{Edit: While PN have not acknowledged this as a bug or a feature, deliberate or mistake, sound engineering or unfortunate requirement ... the one thing they've tended to be happy about is to leave my line on an artificially-high profile. That works until I have an unfortunate DLM episode that ultimately returns the profile to "normal".}

My only statement is that it isn't the Current line speed itself causing the problem. If they used the IP Profile itself in their system the problem would still be there.

I'm sure the problem would still be there too - it seems to be an deliberate configuration choice within the Plusnet system where their choice of throughput allowed when the "Current Line Speed" is labelled 77.4 is insufficient to fully utilise the link.

In the end, you're both right. The 200Kbps in CLS makes almost no difference. But the 2Mbps difference between what *is* and what *could be* is significant.

It could very well be a systemic problem in the interaction between that and the traffic prioritisation system when passing data through at such speeds. Or it could simply be that the buffering system that is used to hold the speed down to the required value is old and under-powered.

There could well be these reasons, or a myriad of similar ones ... but Plusnet have chosen to never enlighten us. Grabbing 2Mbps might be sound engineering, but the absence of an explanation leaves room for conspiracy theory to grow.

(I'll add that I think the explanation is unlikely to ever surface from the new Plusnet. It is something of a surprise that it never did from the old Plusnet, however).

Do we even know it isn't caused in the BT Wholesale cloud? We need some IDNet, Zen, AAISP results. Infinity may not be reliable for this purpose as I believe it's handled differently within BTW.

Two things suggest not.

a) Other subscribers, on other ISPs, seem to report results around 75Mbps all too easily.
This suggests that there isn't a reliable common explanation for a BTW-based cause.
b) A configuration change wholly within Plusnet is enough to release this missing speed.

But who knows? It certainly could be some strange interplay between PN and BTW.

Edited by deleted (Wed 22-Jul-15 10:43:00)

it is supposed to be so plusnet's downstream QoS works and improves your line, because there has to be a unused amount of capacity on the linerate for QoS to work properly.

However all this seems to go to pot when I analyse what happened after I moved to sky, in short the experience on sky is better, e.g. samknows tests no longer cause my latency to spike anywhere near as high. I also get a better bufferbloat score on bufferbloat tests (without router side QoS).

e.g. on both sky and plusnet if I download a plusnet game and have no router side QoS I get packetloss, steam opens dozens of connections and acts like a p2p app. In theory plusnet's QoS system is supposed to save me from that but did nothing. Router side QoS can control it but is a bit of a pain to tune right as ingress QoS is not supported as much as egress QoS.

The reason I think plusnet's QoS is ineffective is simple, they still buffer a ton of traffic so it does nothing to maintain latency whilst downloading.

Edited by Chrysalis (Wed 22-Jul-15 12:19:53)

You forget my point about your post .

In reply to a post by WWWombat:

Plusnet's IP profile system does seem to lop 2-3 Mbps off the possible throughput speed on an FTTC line synced at 80 Mbps.

You do not know that the (agreed) loss of throughput is due to the Current Line Speed system.

At the end of your post you say the question as to what causes the loss of throughput is not put to bed.

That is the contradiction in your post. At the start you blame the CLS, at the end you say the cause isn't known.

I don't say the CLS isn't involved. I do say I don't believe it is the only factor.

In reply to a post by Chrysalis:

it is supposed to be so plusnet's downstream QoS works and improves your line, because there has to be a unused amount of capacity on the linerate for QoS to work properly.

I agree that this is a perfectly plausible, rational, explanation, though I'd buy it better if it only sliced a few kbps off the top.

Personally, however, I wouldn't rate a QoS system highly if, when trying to squeeze high priority protocols into a fully-occupied line, it had the side-effect of limiting how full the occupied line could be when no high-priority traffic was present.

The problem is that I've seen no indication from PN that this is indeed the case - either as a deliberate measure or an unfortunate artifact.

It is interesting to see the results of your comparison to Sky. Are the bufferbloat tests significantly different?

In reply to a post by RobertoS:

You forget my point about your post

You do not know that the (agreed) loss of throughput is due to the Current Line Speed system.

I didn't forget, but I equally didn't give enough emphasis to what my experimental data shows.

You're right that I don't *know for certain* that the problem can be put down to the CLS system, but over 4 years, the various results I have seen tell me that this is the only location it could be. If I were part of Plusnet, and had access to their internal systems, that is the only place I would be looking ... but I'm not, so I can't investigate further, and have to leave it at that. I accept that.

Why am I convinced that the cause lies within the CLS system?

I started with no correlation. The very earliest issues appeared to be related to switching gateways on PPP-reconnection, but there was no strict correlation to that either (much like the recent congestion issues).

Over time, I had eventually made an informal correlation between the highest speeds & an excessive CLS-value, and the same correlation between the lowest speeds and "normal" CLS-values. But I had no way to change CLS-value in a controlled manner, and perform decent experiments; but occasional changes (either at manual request, to set artificially high values, or automatically-induced, to set regular values) helped build the case over the course of a couple of years.

The final correlation came when, as I mentioned in my original post, I did some testing with Dave Tomlinson. He made changes to the CLS value that helped establish, in my mind, the direct correlation between CLS value and truncated speed.

(Aside: As things ended, I had to stop detailed testing because of health issues. The next thing planned would have investigated how CLS settings affected behaviour under load - giving more indication of QoS balance. I wasn't up to concentrating on the detail needed for that, at the time)

For me, I am happy to continue to believe that the loss of throughput is an established feature of PN's connections, and I am as happy as I can be (without becoming a PN employee) that the CLS system is the host of the cause. The combination of these two is what makes me say that "The question of whether this happens has been put to bed."

I further state that "The question about why it happens has not" because we have had no input from PN staff; we cannot know what it is about the CLS system that turns the loss of throughput into fact. Putting the blame on CLS is not the same as understanding why CLS behaves this way.

To me, both statements stand, and are not a contradiction.

I do recognise that, for anyone else to believe my position, they also have to accept my interpretation of my experiments & results.

And with that, I'll have to withdraw from the debate, as I won't be around much over the next two weeks.

In reply to a post by WWWombat:

And with that, I'll have to withdraw from the debate, as I won't be around much over the next two weeks.

If that means you will be having some treatment for the ill-health you mention, I wish you well.

If merely on holiday - enjoy .

If working away from home ....

Edited by RobertoS (Thu 23-Jul-15 10:45:05)

Ta. The health thing rumbles on, but without quite such an impact to concentration levels.

But this break is "just" a holiday

In reply to a post by WWWombat:

But this break is "just" a holiday

There isn't such a thing as "just-a-holiday"!!

Make sure you have a good one!

in some test cases yes.

One scenario had me scratching my head for weeks, when I enabled QoS using the asuswrt GUI, the buffer bloat remained high on the upstream which I was putting down to an issue with the router (and it may still be) after the sky migration that issue went away, on plusnet I had to do some custom QoS on the upstream to get buffer bloat under control, so either a plusnet issue or a pppoe related issue on the router.

I think the isp is more likely to have an effect on downstream buffer bloat, on the downstream side of things the difference is not big, but if I analyse buffer bloat with no QoS management on the router, sky is superior to plusnet. The latency doesnt spike anywhere near as high when the line is busy, however the packet loss seems to also be higher on sky, the packet loss is only an issue when downloading with steam tho (possibly also with torrents but not used any torrents recently). Both isp's had packetloss when downloading with steam at full speed but I think is more severe on sky. Which suggests sky dont buffer so much traffic. In both cases if I have downstream QoS on the router it removes the packetloss.

Also i have found reducing the downstream speeds via QoS generally at my sync speed (72-74mbit) at least 0.5mbit needs to be free to see noticeable affects on latency, but with things like steam which opens dozens of download connections, more like 2mbit needs to be taken off.

This is why I see plusnet's QoS as a failure, if it was working as promised, then I would expect to see no packetloss whilst downloading from steam but i did, not so bad as sky but still enough to affect other activities.