In reply to a post by RobertoS:

It is something wrong in the Plusnet network causing it. But (was it you?) as someone has posted, their real-life use isn't impacted. Just the tbb custom protocol speed test.

I said that last time (2015) but this time around I've just not been affected.

Well that's not quite true. Between Sunday evening and Tuesday evening last week I had continuous low level packet loss and wasn't aware of it:

http://www.thinkbroadband.com/ping/share-thumb/1150f...

Then Tuesday night I was swapping a router out and got an horrendous speed test result and awful packet loss:

http://www.thinkbroadband.com/ping/share-thumb/f636b...

But bouncing the connection fixed it and seems fine now.

http://www.thinkbroadband.com/speedtest/button/14821...

For all I know it could have been related to swapping routers. Unfortunately as I now use the HTML5 tester there's no record of what test results I got between Sunday and Tuesday. It's very likely I ran at least one test and as I didn't see any need to check my TBBQM it suggests that the packet loss wasn't impacting the TBB tester at that time.

Edited by Andrue (Mon 19-Dec-16 20:35:05)

In reply to a post by RobertoS:

It is still valid.

I think its fair to question given there is the "new network" which is unclear what that is. Also majority of plusnet's traffic management was put in place long before FTTC, and when end users were only on ADSL/ADSL2+ lines, so the entire scale of the operation has changed. I personally wouldn't be surprised if a lot of it has been removed thanks to BT investment in trunk links. Always better to increase bandwidth than spend money trying to manage end user traffic. (NTL, now VM learned this the hard way in 1999).

Just traffic types.

Your examples don't explain why other ISPs don't have problems without similar traffic management. How do AAISP handle 2,000 customers streaming UHD from Netflix ?

Not seeing an issue here tonight - sync is currently 57,821 / 9,173 kbps.
http://www.thinkbroadband.com/speedtest/results.html...

You are currently connected to gateway psb-bng03.
This is located in Southbank Point of Presence.

I wonder if there is an issue with certain home routers too?

Edited by jchamier (Mon 19-Dec-16 21:36:37)

This seems to be the best to use, as its in their legal section

https://www.plus.net/help/legal/key-fact-indicators-...

8.00pm - 10.00pm each day VOIP and Gaming get priority and that is the only "Traffic prioritisation to optimise network utilisation"

so nothing is blocked, nothing is slowed down, just voip and gaming prioritised in a 2hr window.

So the http vs the specific port is a red herring, that and the dscp flag that shows priorities is the same for both.

I think basically we are arguing over nothing.

Your link specifically describes their traffic management and how it works. That means they have the kit to do it in place, with all traffic going through it. That kit basically works by analysing the protocols in use by the traffic. That's what distinguishes VOIP and Gaming from browsing, streaming and so on.

It also explains that at times of high network load it will apply to all traffic on the network.

All I am saying is that in the major changes being made to the network that traffic management has in some way, perhaps only at some gateways, got screwed up. Exactly as it did a few years ago. When the same statement was made about always aiming for capacity for everything.

See this 2012 post by the chap who was at the time in charge of network capacity planning and provision. Note the beginning of the second paragraph.

Nothing has changed in the methodology, just they've dropped the confusing titles and now just have Low, Medium and High.

As for nothing being slowed down, as Kelly says - high priority stuff tends to be low volume. But if you have a fixed amount of bandwidth and you prioritise one kind of traffic, you inevitably slow other types. The only question is - is the slowdown noticeable?

The 1x and 6x problem is not designed in. It is a malfunction plain and simple. Typical solving time with Plusnet, 8-15 months.

NOTE: What you posted is correct for the flash version...

On the HTML5 tbbx1 is just 1 http download rather than the six of the multi thread test, same download method

Thanks Andrew. I shall watch out for that when people say which they were on.

In reply to a post by RobertoS:

As I pointed out earlier, the 1Mbps is a custom protocol on port 4095, which Plusnet traffic management will have at the bottom of the priority list if there is congestion.

The 6x is HTTP on port 80, with higher priority.

This is not true, if you use wireshark you can see what values plusnet use for prioritisation, (the dscp flag in the tcp header) and http and the customer port both are the same value, so there is no prioritisation difference between the two streams of packets.

Not sure what is different though and what in the network could be having such an impact. The only things i can see on wireshark are the 4095 stream is treated by wireshark as individual packets, whereas on http it knows the data is part of a bigger PDU.

That and the TCP window scaling for 4095 is coming in at 128 on a 663 windows size vs a http window of 161 and -1 (unknown) scaling size.
So not sure if for some reason the 4095 stream isnt scaling the TCP window correctly and so cant get the speed up whereas the http one can. I dont know enough low level TCP to figure that out yet so will have to go do some reading on TCP window scaling.

Neither show any packet loss or retransmissions.
The 4095 takes slightly longer for the computer to sendd an ACK message too, but that should be consistent for all tests ano not explain why there is a gap, unless flash itself runs out of resources on a computer and struggles (i know my pc though is not low on resources!)

Another correction, if people are seeing our FLASH speed test using port 4095 then I'd be shocked seen as it is configured to normally use port 8095.

ALSO the non-flash version is using TCP Port 80 since single thread is just a single HTTP download, or port 443 is the HTTPS page is loaded.

As Andrew has just pointed out, my 4095 was incorrect in my earlier post. It should be 8095.

First speed test this morning - no other traffic (using Task Manager to check Ethernet traffic)
and using the HTML5 test http://www.thinkbroadband.com/speedtest/button/14823... got the low constant 2Mbps x1 result.
Pressed the test again button and back to normal.
http://www.thinkbroadband.com/speedtest/button/14823...

So in my testing the very low x1 can be replicated in either the Flash or HTML5 speed testers.