Congestion?

Just me or does this look like pretty stereotypical congestion?

Seen average and maximum latency increases at peak time especially on a Monday, the busiest day of the week for consumer broadband networks, for a little while now.

Suspect it's hit the point where a buffer in some kit isn't holding the data anymore and it's getting dropped.

BTW I'm on a train heading home, hence on this forum. When I get back it's off to a relative to see in the new year with fizz

Very, very happy, healthy and prosperous new year to all of you. x

for a plusnet graph that latency is decent, but the packetloss isnt. Looks like congestion to me, I assume jumping gateways doesnt help?

Happy new year.

Edited by Chrysalis (Wed 31-Dec-14 21:05:58)

Did I just answer you on the PN forum?
http://community.plus.net/forum/index.php/topic,1353...

For me, the odd extra yellow pixel means almost nothing: 1% of pings being delayed by 1ms will cause that. That can happen in just about any router, anywhere.

The fact that the blue pixels have not increased tells you that the average delay has stayed the same - so over 50% of pings are getting through without even a 1ms delay.

The smaller yellow spikes definitely say things are getting busier - but without a similar change in blue, it still applies to only a small minority of packets. It is easy to cause this effect just by using the connection. Tall yellow spikes seem to become visible when you run a speedtest, because that delays a few ping packets badly, but the test is over before it can affect the average by much.

In days gone by, the 9-10pm busy hour would be highlighted with a broad yellow peak, of perhaps 10-20ms extra, with a small increase in blue. That, to me, is much more of a sign of broader congestion... yet you show no sign whatsoever.

The red packet loss is different. It indicates either a discarded packet due to congestion, or a packet that was lost due to a noise burst on the DSL connection.

However, packets discarded because of congestion will also be surrounded by packets delayed by the same congestion ... so you'd be bound to see much more yellow, and almost certainly some blue too.

This one looks more like my expectation of congestion:
http://www.thinkbroadband.com/ping/share/abc235376e5...
(live graph, so what I'm looking at will disappear in 24 hours)

Happy New Year to you too...

There's a section on interpreting BQM's too:
http://www.thinkbroadband.com/faq/sections/bqm.html

The examples there are *way* more serious....

The only other possibility would be there is some local interference to him that is due to a device that is turned on at peak time, but there is other complaints on the plusnet forum of packet loss and apparently BTw upgrades are suspended for a period of 3 weeks until next week.

Packetloss can be caused by congestion without significant latency increase, I think it depends on configured buffering levels.

In reply to a post by WWWombat:

The red packet loss is different. It indicates either a discarded packet due to congestion, or a packet that was lost due to a noise burst on the DSL connection.

However, packets discarded because of congestion will also be surrounded by packets delayed by the same congestion ... so you'd be bound to see much more yellow, and almost certainly some blue too.

Depends where in the networks the congestion is and how the devices deal with it.

I see no reason to equate the loss with a noise burst and the error counters on my Huawei modem don't show a spike commensurate with that period.

The graph you posted doesn't look like congestion but heavy usage of the connection. Congestion across a wide cohort you'd expect to ramp up and tail off far less abruptly.

I have seen congestion strong enough to reduce download speeds by 75% only increase average latency by 10ms or so. BTW don't use the same equipment throughout and different BRAS / LNS handle congestion conditions differently.

The BRAS I am connected to has had a software update in the past couple of months which, again, may have changed its behaviour. WFQ should handle smaller packets before larger ones, hence if this is being used TBB meters will 'flatter' somewhat.

The loss of performance is minimal, 15% or so, packet loss not ideal but we'll see how things run.

Okay I check now I have a few minutes indicated that the packet loss was also present, and corresponded with the slight increase in latency, on 28th, 29th and 30th of December. Not present on 31st presumably because of lighter network utilisation on that date.

It's very minor, and I'll wait until BT Wholesale come to life again and see if there are actually issues.

EDIT: Was just pointed out to me on the PN thread that there is packet loss right now. Quick check via the TBB speedtest shows pretty unequivocal congestion.

Edited by deleted (Thu 01-Jan-15 16:50:20)

I would expect you to be feeling it tho, a 1% packet loss affects things way more than a 1ms bump in latency.

In reply to a post by Chrysalis:

I would expect you to be feeling it tho, a 1% packet loss affects things way more than a 1ms bump in latency.

I am feeling it, however I seem to have become accustomed somewhat to it and ignore the slower loading webpages as just part of the experience.

1% packet loss isn't a massive difference maker in the grand scheme except with connections with a high BDP. The vast majority of the content I consume is either based in the UK or at very least has a CDN node in the UK hence a fast retransmit and all is good.

Edited by deleted (Thu 01-Jan-15 17:11:15)

In reply to a post by Ignitionnet:

Depends where in the networks the congestion is and how the devices deal with it.

...

WFQ should handle smaller packets before larger ones, hence if this is being used TBB meters will 'flatter' somewhat.

True. If the network devices are starting to employ queues that are more QoS-friendly than pure-FIFO, then you're right - the evidence in a ping graph will look very different.

The example graph I picked to show congestion was indeed a poor one, with bad ramps. It was the best I could find on the spur of the moment... perhaps because the old evidence for congestion kinda hides nowadays. I then found the FAQ examples, but they're not the best either.

For the ping graphs (which I assume are UDP based), then any kind of WFQ is likely to stop the obvious signs ... until wham, some packets get dropped. In that case, your example graph is probably going to become the best kind of indication we get for congestion. That doesn't feel like a lot of warning to me...

With something like RED or WRED working on TCP flows, I guess you get to see random packet drops kick in earlier than "total congestion", aimed at slowing each TCP stream. You wouldn't see this on the ping graphs at all, but I imagine the kind of single-threaded slowdown visible on your TBB speedtest would be the best indication.

IIRC, "old-style" congestion would affect both the single-threaded tests and the multi-threaded-tests. I imagine that signs like your graph (very slow single-threaded, but relatively healthy multi-threaded) are a sign that some form of RED/WRED is in place.

I see no reason to equate the loss with a noise burst and the error counters on my Huawei modem don't show a spike commensurate with that period.

OK. It is the most likely "other" cause to dropped packets, but easy to check with an open modem.

But thanks for the heads-up... I'll have to change my ideas of what I'm looking for in the graphs...

In reply to a post by WWWombat:

With something like RED or WRED working on TCP flows, I guess you get to see random packet drops kick in earlier than "total congestion", aimed at slowing each TCP stream. You wouldn't see this on the ping graphs at all, but I imagine the kind of single-threaded slowdown visible on your TBB speedtest would be the best indication.

IIRC, "old-style" congestion would affect both the single-threaded tests and the multi-threaded-tests. I imagine that signs like your graph (very slow single-threaded, but relatively healthy multi-threaded) are a sign that some form of RED/WRED is in place.

The symptoms are commensurate with simple dropping of packets. Packet loss is capping each TCP flow traversing the choke point at 8-10Mb or whatever, hence the 6 x TCP flow test will show a significantly better result than the single flow.

This isn't fancy queuing it's relying simply on TCP's own congestion control. It's a reason why P2P has been so problematic on networks in the past, especially before the creation of UTP, and why Usenet continues to be. Loss being caused by rate limiting on a port will cause a per-TCP flow limit and those applications, being multi-threaded, will crowd out single flow applications such as streaming.

RED is, actually, more likely to bring single-thread and multi-thread results closer together.

http://www.speedtest.net/result/4033567193.png

--- maroon.linx.net ping statistics ---
100 packets transmitted, 98 received, 2% packet loss, time 99161ms
rtt min/avg/max/mdev = 15.185/26.627/199.396/18.501 ms

Download speed achieved during the test was - 15.74 Mbps
For your connection, the acceptable range of speeds is 51.46 Mbps-64.32 Mbps .
Additional Information:
IP Profile for your line is - 64.32 Mbps

Ya.

you not alone, I see me and others joined into your plusnet thread.

Here is my latest, the single threaded was flatlined as if throttled/rate limited.

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

Mine seems OK, testing wirelessly.

Maybe we should also post our gateway at the time of the test? See if there is any commonality in the poor ones. (Thinks - bng series). I'm currently on ptw-ag03.

On the plusnet forums I did post the gateways.

one was ag06 the other was ag08 both pcl

The difference between me and ignition tho, he has clear packetloss, I dont.

Edited by Chrysalis (Thu 08-Jan-15 10:42:48)

as an update I also have packetloss now, speedtests below 30mbit tonight.

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

I see you moved to a bgn gateway at ~13:15?

yes.

http://clueless.aaisp.net.uk/congestion.cgi

BT 21CN LBV-PK, all BRASs 0.07% Packet loss approx 6pm to 10pm

What does "LBV-PK" represent? Obviously not a single exchange, as AA's XML classes it as a "region" instead.

They are the BT 1141 codes. You can google them and you should find a spreadsheet with them.

LBV/PK - Hunslet

In reply to a post by AndyHCZ:

They are the BT 1141 codes. You can google them and you should find a spreadsheet with them.

LBV/PK - Hunslet

This.

MYHLT LBV/PK HUNSLET LS11 5TD

EDIT: Hunslet is an NGA headend, so potentially it's in the 'region' section as it's affecting connections backhauled via Hunslet, not just those whose copper is homed at Hunslet.

Could be congestion on an SVLAN, could be congestion on the Cablelink(s).

Edited by deleted (Tue 13-Jan-15 11:36:41)

Ta - that gives a few more clues.

I also found a reference to Hunslet being known as Hunslet Parkway, which might go some way to explaining the code.

I just found an (old) document that suggests the 21CN nodes will be identified by their 1141 code; perhaps AA end up using this code because it does indeed lie in something that can't be solely identified with the one exchange.

Interesting question, then: could an SVLAN comprise users from a mixture of the exchanges covered by the one headend? I guess it could...

In reply to a post by WWWombat:

Interesting question, then: could an SVLAN comprise users from a mixture of the exchanges covered by the one headend? I guess it could...

Absolutely. The SVLAN is a link between headend and the rest of the BTWholesale network.

Howdy.
Figured I'd tip my hat into this as I've noticed slowdown every evening and weekend since i upgraded to FTTC on the 5th.
Couple of TBB tests, one at 6pm, one at 6.20
This is the worst I've had it since I got hooked up :/ Although there is one difference with the tests, the first I was on ptn-ag02 (telehouse north...and with an INFONET IP, people on teamspeak were asking why I'm american ) and the second on ptw-ag02 (telehouse west)
http://www.thinkbroadband.com/speedtest/button/14211...
http://www.thinkbroadband.com/speedtest/button/14211...

Edited by NBK (Tue 13-Jan-15 18:28:37)