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...