Expected ping speeds and spikes on BT FTTP

I've ad a BT FTTP 150/30 connection for about a month now and the throughput is pretty much spot on but at times there have been a few time out on websites or parts of them while browsing and a couple of other indicators of delays.

Using a wired connection I generally get a ping time of about 6-7ms to somewhere like google.co.uk which is great and improves on the previous FTTC connection by about 5ms.

If I leave a ping running in the background then at times it jumps a little to 50 or even 100+ms before coming back down again.

I've just switched out the stock Smart Hub 2 router for a Netgear R7800 so that I can use the Think Broadband monitor to look at the connection and generally I think the connection is better.

If I run a speedtest or max the download or upload connection otherwise then the ping suffers as preswumably this is bufferbloat and to be expected but I'm also seeing a few other high pings even when there is little else going on/

https://www.thinkbroadband.com/broadband/monitoring/...

Ignore yesterday's readings as I was testing and maxing out the connection but you can see there have been a few high pings today (also ignore the dropped packets at 3pm today).

So my questions are, is this to be expected when the connection has some general light use going on but nothing that should max it out?

On the R7800 I've tried with and without QOS enabled and I've also tried the modified Voxel firmware and the results are the same.

With QOS enabled and simply limiting the connection to about 85% of it's max if I run a ping to google and then also a speedtest the ping times go high for a few seconds presumably as bufferbloat is occurring before the the limits kick in and the ping times come back down (although they're still higher than when the connection is idle).

Again is this what you would expect with QOS or should it never be allowed to get too high?

I have moved ICMP from medium to high priority in the router's QOS settings.

All in all the connection is generally pretty good and better with the other router but the geek in me would like to understand what is going on and make it as good as possible. Also if it makes any difference FTTP only recently came to the area and we must be one of the first to get it (the first on our splitter).

Edited by StuB (Tue 08-Sep-20 15:33:08)

A little update on this it appears the main latency spikes are occurring when my other half is using voip calls for work via 8x8 in a web browser.

While doing this the bandwidth used is low and it looks like the data is classed as general web traffic.

Would you expect this to affect the monitor this much.

Generally the connection seems to be working fine now even while these calls are made but I'm curious as to what is going on.

Today's monitor

Edited by StuB (Thu 10-Sep-20 15:08:21)

In reply to a post by StuB:

A little update on this it appears the main latency spikes are occurring when my other half is using voip calls for work via 8x8 in a web browser.

While doing this the bandwidth used is low and it looks like the data is classed as general web traffic.

Would you expect this to affect the monitor this much.

In short, yes.

What matters most for routing performance is packets-per-second, not the traffic volume (bits-per-second). The VOIP calls are sending large numbers of small packets, whereas a simple file transfer will send a small number of large packets.

The CPU work for sending 10 x 150 byte packets is about ten times higher than for sending 1 x 1500 byte packet, although the bandwidth used is about the same.

It seems likely that your router is very underpowered for the job in hand.

+1

When designing Core networks for VOIP some years back, the core could only be dimensioned to about 10% of it's actual; capacity for VOIP because of the huge number of small packets. You could use data to fill the rest if you could ensure it was only file transfer type traffic using large packets.

VOIP is usually 10 or 20ms packetisation to keep the quality reasonable, this leads to a lot of small packets and headers start to make up a significant portion of the bandwidth as well. The bandwidth you use is small compared to the processing load, real time video can accentuate the issue.

I too am experiencing odd latency with not so much usage, around 10Gb a day total download between 5 devices
TBB TodayPing

That is today's snapshot of my graph and the latency is odd even at night with nothing on, the red packet loss at 3pm is when i restarted router to see if it made a difference and the latency around 11pm is when i was hammering the connection with a couple downloads
Downgraded to 50/10 from 150/30 in august as do not need the bandwidth but im starting to debate 80/20 as the latency was never like this on 150, whereas if others are experiencing variations then me changing to a higher tier package is pointless atm

Your BQM is considerably worse than the OP's.

I would say the OP's BQM looks good, perfectly normal.

I would say your BQM is pretty shocking for FTTP. It looks more like a Virgin BQM.

its not right I agree, but it was never like this on 150/30, only since i downgraded to 50/10
Am using an ASUS router with QOS enabled 48d/9u in the settings to allow for overheads and the BQM and performance is worse without it enabled,
My theory is that I could be on a congested VLAN?7
the night of the downgrade the router disconnected for a few mins at midnight and then re-connected with the lower speed in place and latency has been questionable since.

candlerb and kitkat,

That explanation makes sense regarding the packet numbers. When a call is in progress it looks like it's transferring about 0.18mbps I'll have to try and look at the number of packets that are being sent.

The router is a Netgear R7800 so I'm a little surprised that doesn't have enough power as it has a lot more CPU power than a lot of routers.

If it wasn't for the spikes when the voip calls are ongoing then it would be fine.

Providing you keep the speeds a little below their max then it doesn't spike much even when large amounts of data are moving around.