Peak time latency spikes

[#1]

My speedtest result was fine at around 6pm with 10ms ping and 53Mbps download. After about 8pm i noticed a slowdown to 2Mbps and 40ms pings. This was on pcl-ag02. Reset connection via router and back up to normal speeds on pcl-ag06.

[#2]

Post back if it drops again please.

[#3]

Back to normal now !

[#4]

One thing I don't get is, if it was congestion in BT's network, would you not expect to see packet loss?
When my exchange had issues, we were getting 5-10% packet loss at peak times. But a lot of people reporting slow downs now are just showing increased pings on the TBB graphs.

[#5]

What if it's a buffer management problem, rather than genuine congestion caused by traffic overload...? Routers these days have very big buffers (not necessarily a good thing!). Buffers filling and draining (rather like traffic on a busy motorway starting and stopping) would increase latency, reduce throughput for individual users, but not necessarily lead to high levels of packet loss, particularly as input rate is matched to output rate for each individual VLAN on the BTW backhaul network.  Just a random thought which may be completely irrelevant!
I'm not clear if this has been firmly tied down to specific Plusnet Gateways, specific Exchanges, or a combination of the two (or the pattern isn't so clear). Is anyone from Plusnet willing to clarify the current status? I appreciate they may not want to point fingers at the moment.
For what it's worth, I'm on FTTC, on Merton Park exchange and currently on gateway pcl-ag07 (although I'm normally on ptn gateways) and have so far never experienced this latency issue.

[#6]

Quote from: Bright

What if it's a buffer management problem, rather than genuine congestion caused by traffic overload...? Routers these days have very big buffers (not necessarily a good thing!). Buffers filling and draining (rather like traffic on a busy motorway starting and stopping) would increase latency, reduce throughput for individual users, but not necessarily lead to high levels of packet loss, particularly as input rate is matched to output rate for each individual VLAN on the BTW backhaul network.  Just a random thought which may be completely irrelevant!

That is how our platform works.  You'll see the buffers fill before you get dropped packets.  This results in increases in latency before the packet is lost.  We aren't seeing either during these periods.  😕

[#7]

I think 'Kelly' might have had the explanation in Reply #219, i.e. the upstream data is buffered.
So, within Plusnet and upstream through the BT trunks, the data flow is buffered and is less likely to exhibit packet loss.
However the packets heading downstream from Plusnet to your exchange are NOT buffered, and under the circumstances where your exchange is overloaded, the data will be arriving at your line profile speed which will be faster than the exchange can deal with, therefore arbitrary packets get dropped and so you see packet loss on the TBB graphs.

[#8]

Quote from: Kelly

We aren't seeing either during these periods.  😕

Just to clarify... by "either" do you mean latency and packet loss? Or high buffer utilisation? Or all three? 
I guess what I was trying to get at was that an "error" in the buffer queue management algorithm could cause some queues to grow quite large, and with so much buffer elasticity (ie capacity) in routers across the network, could result in a considerable increase in latency but little lost traffic.  I'm sure you're way ahead of me on this issue, and apologies for covering old ground - with such a long thread I couldn't face reading every page!

Quote from: purleigh

However the packets heading downstream from Plusnet to your exchange are NOT buffered, and under the circumstances where your exchange is overloaded, the data will be arriving at your line profile speed which will be faster than the exchange can deal with, therefore arbitrary packets get dropped and so you see packet loss on the TBB graphs.

I'm not sure I understand why downstream data would not be buffered but upstream would...? Or you mean that under congestion, with much bigger flows down than up, the downstream buffers would be more likely to run out of capacity?

[#9]

Just chuck my tuppence worth in (and I'm no Network expert), w.r.t. Purleigh's DS ideas 1) Surely the Current Line Speed addresses that and 2) There seems to be a broad spectrum of people (and exchanges) seeing these issues so there would have to be a hell of a lot of overloaded exchanges 

[#10]

[quote=Bright]I'm not sure I understand why downstream data would not be buffered but upstream would...? Or you mean that under congestion, with much bigger flows down than up, the downstream buffers would be more likely to run out of capacity?
What I was trying to express when I said 'downstream from Plusnet to your exchange' was the 'leg of the journey between Plusnet and the exchange' is unlikely to be buffered.  On that final leg of the journey, the rate at which packets are sent to the exchange are speed limited by the Plusnet line profile, to avoid arbitrary packets being dropped by the exchange (when working normally - i.e. NOT overloaded or congested) BECAUSE the exchanges DON'T buffer the incoming data stream.

To add to 'Anotherone's point,  I have been seeing evening latency problems and I don't believe my exchange has EVER been congested, which is why I don't see packet drops and rarely see my speedtest results suffering.

[#11]

During the evenings I'm finding that the sound quality on VoIP calls is absolutely dreadful - at best it's just about usable but quite a bit of distortion, at worst it drops out altogether for seconds at a time. Looking at the latency graph I can see why!

[#12]

Edit: I thought all VoIP traffic was Titanium? Edit2: Unless the Upstream is the source of the VoIP issue?? (graph won't apply then)
So there's 3 of us here on 20CN connections seeing the latency peaks (no worse than any one else?) but the Speed impacts (on 2 of us at least) certainly aren't as severe as the faster connection, Fibre in particular, as mentioned by Kelly IIRC. I'll have to run some time sensitive apps at the peak times to see what the effects are on packet drops. I'm normally only doing a bit of browsing at those times.
My latency increases seem to be consistent with the general pattern, although there are obviously some related to my own activity, but I get an odd few at assorted times which I suspect may be due to activity through the local exchange - the VP status has been Green for a long time, but that doesn't mean there isn't congestion - putting my cynic hat on, if there is any congestion on my exchange, I don't believe BT will own up until it get's that bad that they have no option as occurred a few years back when we had to make a sort of "class" complaint to BT (because it was spread across various ISPs - Market 1 exchange!).

[#13]

It's supposed to be Titanium but Wiresharking shows DCF on the incoming packets is 0x00 which I believe is best effort. While call quality hasn't been great as a result it had been usable until the last few weeks. Since Unlimited was introduced it's been far worse so I suspect it's associated with the problems in this topic.

[#14]

That sounds like a traffic management bug, probably best not to go into detail on that in this thread?

[#15]

@Purleigh
Thanks, got it. As you say, the rate of traffic flowing into the network from Plusnet's gateway should be the same as the rate flowing out to customers down their broadband links, because Plusnet profile rate = BT IP profile rate. But there would only be no buffering if the network between input and output:

• has (effectively) infinite capacity, or


• the distribution of traffic across the network exactly matches the distribution of capacity, and the traffic is statistically evenly distributed in the time domain ie the load is steady and there aren't peaks and troughs in load.

In practice neither of these ever happen, so you get load hot spots at particular nodes, which vary with traffic level over time. Networks are never designed to carry the absolute maximum peak traffic they are ever expected to be offered (it wouldn't be cost effective). At your exchange, as one customer settles down to watch Eastenders on iPlayer, another starts downloading a game, and someone else emails their holiday snaps, your own traffic will get buffered as necessary to try and make sure everything gets through and higher priority streams (eg Eastenders!) don't have to wait for someone else's emails.
@jelv
That's an interesting latency graph! Could I ask where it's from? Looks like latency data for Plusnet gateway links connected to BTW IPstream Connect nodes at Faraday and Colindale exchanges?? Do you know what the y-axis units are? Also, it says "best effort" so it's just for the best effort traffic?  Just curious 
Sorry to see you're still having trouble with your VoIP traffic priority. What's different between your set-up and mine? My VoIP traffic is tagged correctly. Very odd.
@Anotherone
I wonder how BT defines congestion at an exchange (since it varies from second to second, hour to hour, day to day). There must be an official definition (eg more than x% of traffic lost during the busiest hour on more than 10 days in a month, or whatever!). Are the latency problems the same on 20CN as on 21CN? (I thought I read a post somewhere from Kelly saying there was an issue with them managing down capacity on 20CN as customers migrate to 21CN, but that might have been a totally different issue...  I get confused!).