State of play after testing by Bob Pullen on 29 December
https://community.plus.net/t5/Fibre-Broadband/Odd-TB...

TLDR: So, it seems that the slow single threaded issue is limited to L2TP (read: BNG's) and Think Broadband's servers. Granted though, this is only testing using a limited number of sources.

https://community.plus.net/t5/Fibre-Broadband/Odd-TB...

I've forwarded the results of our testing to those looking into the problem. I think it would also help for us to reach out to our contacts at AAISP and Zen if it's reported they've fixed the problem (is it?).

I get a low tbbx1 result every now and again such as this morning. I always find that if I immediately test again I get a normal result though like this. It's like me, ok once I'm awake and up to speed 8^) .

I have the same issue with the single tread at about 1mbps and the 6thread at about 35mps.
I have had a fair bit of instability with speed of between 16mps and 38mps.
Re booting the router sometimes up the speed to the 35mps+ range
Discussions with plusnet inconclusive but my profile has been changed?
A lot of openreach engineers about due they claim to the old bulk aluminum phone cable from the exchange to the old pcp cabinet causing problems..
I assume that there is a copper wire from the new fibre cabinet to the old pcp cabinet In which case there is a copper aluminum connection which in damp conditions could be problematic
I assume that the copper wire from the pcp cabinet to my house has not been touched.
Any thoughts.

If issue is aluminium its presence would show up due to higher attenuation figures per km of cable involved.

If the Al is impacting on the DSL it should also show up via wandering noise margins and more errors.

In reply to a post by jeremy35:

A lot of openreach engineers about due they claim to the old bulk aluminum phone cable from the exchange to the old pcp cabinet causing problems..
I assume that there is a copper wire from the new fibre cabinet to the old pcp cabinet In which case there is a copper aluminum connection which in damp conditions could be problematic
I assume that the copper wire from the pcp cabinet to my house has not been touched.

On FTTC there is a patch panel installed in the PCP and your phone line from the exchange is connected to that.

That patch panel has two copper pairs per user between it and the FTTC cabinet. One pair carries the phone signal between the two cabinets. The other carries the combined signals between them.

At the FTTC cabinet is a DSLAM where the fibre signal from the headend exchange (which may be different from your phone exchange) is converted to VDSL2 and merged with your phone signal, and vice versa on the return journey. Loads of filtering at the FTTC cabinet.

The second copper pair carries that combined signal back to (or from depending on the direction) the PCP and the copper from your house to there is connected to the return port on the patch panel.

There is far less chance of the aluminium causing trouble than there was before you had FTTC on your circuit.

In reply to a post by longedge:

I get a low tbbx1 result every now and again such as this morning. I always find that if I immediately test again I get a normal result though like this. It's like me, ok once I'm awake and up to speed 8^) .

Similar to my experience. 99% of the time the test runs fine at 65Mb/s or thereabouts. But day before yesterday I got a bad result. So I aborted it and immediately re-ran it and got a good result. I'm on the bng03 gateway and have been for a while.

from what I understand it has not been removed, but rather plusnet staff have stated they keep capacity high enough so it never needs to kick in on a network level. In other words I agree with RobertoS. Bear in mind they have never guaranteed it will be the case 24/7/365.

The behaviour people have reported here I can not see been anything else than malfunctioning traffic shaping, congestion would have it at higher speeds.

In reply to a post by Chrysalis:

The behaviour people have reported here I can not see been anything else than malfunctioning traffic shaping, congestion would have it at higher speeds.

I've seen it on older ISPs when network links fail.

How would traffic shaping (even faulty!) produce results like this?

http://www.thinkbroadband.com/speedtest/results.html...

That's with the non-flash test so different protocols aren't in use either.

a traffic shaper can get confused depending on the number of streams.

whilst that result is pretty much impossible for bog standard congestion be it cpu or network congestion. As the x6 test is way higher than 600% of the x1 result.

Another possibility is that DPI equipment is malforming the packets so things like rwin negotiation are getting screwed up and preventing the tcp speed ramping up, the this can probably be diagnosed with wireshark.

Edited by Chrysalis (Sun 01-Jan-17 20:24:23)