Is this latency normal?

This is a new BT FTTP connection, 500Mb/s. The speed is being delivered when tested via an ethernet connection, but the latency shown in the BQM screenshot (link below) worries me. Elsewhere I have Virgin FTTP connection which shows virtually no yellow. I am using a Draytek 2926, not the BT device.

Thoughts much appreciated.

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

Swap the Draytek for the BT router and test again over 24 hours.

If I remember correctly, the TBB yellow line shows the maximum latency out of 100 pings.

You could get intermittently high latency if you are filling the link with traffic, because the pings have to sit behind other packets in a queue. Whilst filling 500Mbps download 24x7 may be unlikely, filling the outbound 70Mbps is possible, for example if you are backing up terabytes of data to a cloud service. Can you get graphs of interface counter stats from your Draytek which show how much traffic you are actually sending in and out?

You really want to be looking at latency when the line is as idle as possible. You could try turning off the wifi and unplugging all your LAN clients for an hour or two, and seeing if the line goes flat.

Remember that these are pings *from* TBB *to* your router's WAN interface. Many routers deprioritise responding to pings, and some will intentionally drop pings when more than a few per second arrive. However (a) if the router isn't busy there's no particular reason for it to wait 200ms, (b) there's no apparent packet loss.

Other ideas:

You can try sending 100 pings outbound to some well-known endpoint, e.g. 8.8.8.8, and checking the maximum latency on the response. Do this several times.

Have you tried the BT-supplied router? This would rule out an issue with the Draytek responding to pings.

I take your point but sadly not so simple, I lose necessary VPN connections, load balancing etc etc. I will see if I can do it over the weekend when SWMBO isn't using it for Teams during the day!

Thanks for the advice, I will try to set up a realistic test and revert if I am still seeing the issue. During the day the line is used pretty intensively for videoconferencing (although there's enough bandwidth for that not to be a factor, surely) but the issue seems to persist overnight when there is nothing going on.

In reply to a post by nieldm:

but the issue seems to persist overnight when there is nothing going on.

Swap to the BT router when everyone has gone to bed and swap back first thing in the morning. At least you will have a few hours snapshot during what is as you say an otherwise quiet time.

Videoconferencing won't be anywhere near the limit of your link.

Really you want to be doing SNMP monitoring of the WAN interface on the Draytek, so you can generate graphs of traffic in/out. If you're using Windows I don't know what's the best/easiest tool for this, but maybe someone else can suggest.

(I use prometheus+grafana but that's a sledgehammer to crack this nut)

Then you can be sure whether the link really is idle overnight or there's some background traffic going on that you weren't aware of.

The Draytek's can be a bottleneck with PPPOE due to firewall usage.

https://www.draytek.co.uk/products/business/vigor-29...

Performance
Firewall: Up to 400Mb/s
IPSec VPN: Up to 80Mb/s
SSL VPN: Up to 45Mb/s

So you need a router capable of 500Mbs over PPPOE to make full use of your connection. No idea if this has an effect on pings. My 2925 has a restriction of 300Mbs over the firewall.

It's not just PPPoE, the VPN performance is also a bottleneck which may explain the poor BQM.

...but Speedtest is reporting the full 500Mb/s. I posted about this, that the router was reporting speeds higher than the quoted firewall throughput, on the Draytek forum last week. It seems quite a few people are seeing the same thing, so it seems Draytek are underreporting the throughput. That said, if you look here - https://www.draytek.com/products/vigor2926/#specs - (the US site), the throughput figures for the 2926 are different and more in line with what I am seeing.

...but this isn't the issue.