Any capacity issues?

[#1]

Quote from: chrcoluk

do BTw have any monitoring for backhaul after the SVLANs?

TSO monitor it at Adastral Park. It's not published to CPs, as far as I'm aware.
I think PN can check the node your traffic is going through (which will determine whether you end up on Faraday or Colindale).

[#2]

Quote from: AndyH

I think the fact that all those users can re-connect and get normal speeds again is showing it might be BTW backhaul after the SVLANs. AAISP certainly have a few cases for this on-going at the moment in the South West and parts of London.

I'm afraid I disagree with you there Andy.    The fact that users can re-connect and get normal speeds again to me shows its highly likely to be Plusnets network.
My SVLAN is blue.  SVLANs are like the old VPs, they are the 'backhaul' up to the point of the bRAS.   From there you join the 'Core' Network.    The whole idea of MSE bRAS is to bring the CORE closer to many  more users and to improve speed and latency.    If there was problems with the Core then there would be far more then a few Plusnet Users complaining.  
When I perform a reconnect I simply get allocated a different PN gateway by the RADIUS server.  Depending upon which gateway Im allocated that then determines where I hop off the Core.   My routing between home, dslam, bRAS, Core doesnt change.  Just the fact that I may say hop off the Core at Faraday or Colindale.   Its Plusnets responsibility to make sure that they purchase sufficient bandwidth at one of these core nodes.
Plusnet appear to have MSILs at Colindale, Stepney and Faraday.  According to the graphs they seem to be ok.   I dont see any flatlining indicative of congestion at any of these points.   So if the MSILs themselves appear ok, then that leaves the APs or Aggregation Points.  - ie the link between where you come off the core and to Plusnets Edge Routers or BNGs.

Whilst I understand that AAISP may be showing issues in some areas, 1) those arent any where near me 2) They record the exchanges - ie the 20CN/21CN backhauls - which would be the VPs or SVLANs.
Its not impossible to have issues on the backhaul SVLANs - these are and always have been a point of contention back to the days when they were VPs.   Its seldom, if ever that you see congestion on the main core.  The CORE is massive when it comes to bandwidth.  Its not in BTs interests to ever let congestion happen on the Core because the UK interwebs would start to melt down.  
The other place where congestion occurs is the MSILs & APs - those are the responsibility of the ISP to ensure there is sufficient bandwidth on their (many) APs between the Core Node and the location of their Edge Router.    

If I can go from 25Mbps to 75Mbps just by swapping gateway..  then to me that points to one of the APs.
---
typo

[#3]

^^ I agree with kitz. Good reading there! I was not surprise Chris Parr say my exchange is Amber. That's why I getting slow speed in evening in the last 2 weeks. 

[#4]

thanks for the insight kitz, very helpful.

[#5]

Quote from: kitz

The fact that users can re-connect and get normal speeds again to me shows its highly likely to be Plusnets network.

I've got to disagree also The fact that you can have a variable performance just be reconnecting to the same gateway multiple times is more likely to point to an issue before the gateway.
On the routing, it's always been my understanding that there are many different paths your traffic can take from the core nodes through the BTW network:

Quote from: dave

Quote The Multi-Service Interconnect Link is where the traffic from the 20 Point of Service gets to the Plusnet networks at Telehouse etc. This traffic can take a different route through the BT 21CN network (from the PoS to the handover locations) which is why you can sometimes find small variance in latency when you disconnect/reconnect? Yes, and will take a different route depending on which BTW WBMC Shared core node you hit. We buy capacity in 40Gbps chunks at Stepney, Faraday, Colindale (twice), and Colombo, with another Colombo due next month and 2 more Colindales on order. At point of connection you could hit any of them and your traffic take a different route through the BTW network.

As PN are on WBMC Shared, responsibility for nearly all the backhaul lies with BTW. This is the premium you pay per Mbps of traffic compared to the standard WBC.
The AAISP issues are also raised by PN (although badly communicated on the PN Exchange page). They aren't SVLAN issues from what I can see, unless all the monitoring for those areas is broken.

[#6]

I think Kitz's suggestion re the AP's is very likely to be underlying cause to what we are seeing  and not an issue with wholesale , unless plusnet ain't been buying enough  capacity from them , but that isn't a fault

[#7]

The overnight maintenance at my exchange didn't make any difference but I notice a major upgrade programme over the next week that also applies to me:
http://status.zen.co.uk/broadband/maintenance-outage-details.aspx?reference=247379
and yet another:
http://status.zen.co.uk/broadband/maintenance-outage-details.aspx?reference=248098
No idea of course if either of them are in anyway related to current issues or will address them.

[#8]

Quote from: deathtrap

I think Kitz's suggestion re the AP's is very likely to be underlying cause to what we are seeing  and not an issue with wholesale , unless plusnet ain't been buying enough  capacity from them , but that isn't a fault

Plusnet do not have their own dedicated APs as they are on WBMC Shared (unless this has recently changed). APs are the responsibility of BTW.

Quote from: Andrue

I notice a major upgrade programme over the next week that also applies to me:

Neither should affect you capacity-wise. One of them is to "carry out platform maintenance on legacy Hub1000 broadband nodes at the following exchange regions" (not 21CN).

[#9]

Quote from: kitz

Hmmm  Im not quite sure if all is fine and dandy here.   I seem to be seeing some sort of weird jitter and/or packet loss.    Look at my throughput graph again in my post above, see how Im getting some kind of weird stutter.   That graph should be a red block, not have missing segments where packets have been lost.   Just checked my line stats, they're not CRCs.

Sure that isn't packet loss? Packet loss would I imagine trash the throughput, as would excess jitter given it'll trigger the same response from the TBB servers as packet loss - they'll think a segment is missing and request a fast retransmit via a selective acknowledgement.
If there were loss you'd see the throughput saw-tooth.
Perhaps more pertinently why would there be packet loss upstream due to capacity issues given pretty much everything is symmetrical on the path?

[#10]

I'll be checking mine hourly from ~7.45 tonight.
Not gonna bother till then since I'm watching a decent team play trash

[#11]

Slow for me here in Scotland's central belt  too
I get 37Mbps down outside peak times.


gateway pcl-bng01

[#12]

Here we go...
(Bolton drew with the trash team so get a replay at the Macron - good but then I lost an ebay auction I've been watching all week  :()
Still on ptn-bng02
I know on the 2nd one HTTP average seems down but I tend to look at divergence between TBB and HTTP of which there is little

[#13]

Quote from: StephenM

Slow for me here in Scotland's central belt  too I get 37Mbps down outside peak times.

Try disconnecting/reconnecting to see if that makes a difference.
Which exchange are you on?

[#14]

Quote from: nbk

Here we go... (Bolton drew with the trash team so get a replay at the Macron - good but then I lost an ebay auction I've been watching all week  :() Still on ptn-bng02 I know on the 2nd one HTTP average seems down but I tend to look at divergence between TBB and HTTP of which there is little

Whereas I'm on ptw-bng02 and whilst earlier things were OK, not so good now:

[#15]

Wow that ping...
I was on ptw-bg02 for a week and didnt really have any slowdown on that gateway