Help: Assess my BQM?

Hi all,

Was hoping someone more experienced might be able to offer some insight into my BQM:

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

I am on Virgin Media Volt M500 which runs into a Superhub 3 in modem mode, with routing and Wi-Fi provided by an Eero 5 mesh system.

To contextualise the obvious changes - from 8am I shut off my linux ISO hosting box to see what the line looked like without it, and I turned it back on again at 12.30pm - so that explains why the blue increases I guess.

I suppose my specific questions are:

- I've read the page on interpreting these results a few times now, but I still feel like I need an ELI5 - what does a broader band of blue ("average latency") actually mean? Does that mean over a certain period the average latency result per min/similar has varied more?

- The yellow (maximum latency) - between 8 and 12.30 on that graph really all that was going on other than passive connections for various household gadgets was me using my work laptop, and nothing very challenging - no zoom calls this morning! - in other words, the yellow between that time period is close to what the "resting state" of my connection is, and I would say that's a pretty typical amount of yellow compared over many weeks of running BQM. Is that a cause for concern? The Guide to interpreting the BQM's example of a healthy connection is practically all green with only a few hints of yellow blips here and there.

If there's anything in here that folk would consider cause for concern, what would you recommend to troubleshoot / fix? I had a Virgin engineer out the other week and he did a few things - tightened connections, changed out some old looking wiring at the local box etc.

Thanks all!

One thing I can tell you is your minimum latency is kinda high.

I am on a faster connection but id expect out latency to be the same.

Here is my graph for compaison

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

Yeah other than the latency being high (if in england) - my virgin BQM from N.Ireland was similar

Thanks! I had meant to ask whether it was line with what I could reasonably expect. Interesting - any idea as to why that might be?

My Broadband Ping

The blue line occasionally getting thicker coinciding with the min latency slightly dropping I think is related to docsis power saving state. I ignore it.

Is this a RFoG connection? They seem to have a higher ping?

In reply to a post by Chrysalis:

My Broadband Ping

The blue line occasionally getting thicker coinciding with the min latency slightly dropping I think is related to docsis power saving state. I ignore it.

You can ignore it for sure. It's when the ping to respond to the BQM can go into a minislot that's already been requested so no need to go through the request-grant-transmit cycle to reply to TBB, straight to transmit as there's capacity left in an existing grant.

Depends where you are in the country to what ping you get. I'm in Yorkshire and mine is closer to the OP's figure than to yours. I also get around 20ms for at least half the day and c.15ms for the rest.

Sorry, only just seen this - thank you! That's good to know.

Thanks for explaining - that's good to know!

In reply to a post by Philce:

Is this a RFoG connection? They seem to have a higher ping?

No idea I'm afraid! How would I determine that?

In reply to a post by Pyrrhic:

In reply to a post by Philce:

Is this a RFoG connection? They seem to have a higher ping?

No idea I'm afraid! How would I determine that?

Are you connected with fibre to a box outside of the house?
It looks like the conversion from fibre to coax adds some latency.

Im sure one of the technically minded readers may know!

In reply to a post by Philce:

Are you connected with fibre to a box outside of the house?
It looks like the conversion from fibre to coax adds some latency.

Im sure one of the technically minded readers may know!

Ah - well, this is where I show my ignorance again there is indeed a little junction box (?) on the front of the house, and it's definitely a coax cable that feeds into the router - whether the wire in the run before the junction box is coax or fibre I don't know and I'm afraid to look - the cover keeps falling off it, and the engineer did a bodge repair using some cable ties for me when he was looking at it.

The engineer did mention I'm connected to the cabinet in the next street along rather than my actual street - I thought this was probably due to proximity rather than anything else (cabinet in my street is right at the other end, whereas I think the one for the next street is physically closer) but he seemed to think it strange. I wonder if that would add to latency if it's only fibre to the cabinet?*

*genuinely, I have no idea what I'm talking about here and whether that makes sense in the context of Virgin Broadband!

Edited by Pyrrhic (Tue 16-May-23 16:13:24)

In reply to a post by Pyrrhic:

Thanks for explaining - that's good to know!

Welcome! On cable and RFoG networks before you can transmit you have to ask for permission and are given a set time period to send your data. That takes at least 2-4 ms depending on the timings set by the cable company. The time periods are in a message called the upstream MAP, and that's sent on the downstream to all devices in the segment at a set interval. The more often it's sent the more bandwidth the cable company loses to the overheads, but with the potential to provide lower baseline latency and jitter.

Also this comes with a loss of upstream bandwidth as there are 'contended minislots' in each message - these are where a modem sends its upstream burst to ask for slots to send data.

This all used to be a problem, actually, as the intervals limited the amount of times a modem could transmit but this was fixed through a combination of allowing modems to attach a request for more data to the last transmission they send, and through allowing modems to group a bundle of data into a single burst, filling empty spaces in the grant with small packets rather than one stream, one request, one burst.

https://people.computing.clemson.edu/~westall/851/do... is out of date now but still holds as far as BQM goes on RFoG - you have no DoCSIS 3.1 channel so it's basically the same as that PDF but on steroids.

Same story on PON networks actually however they both pre-emptively provide some bandwidth to each ONU and the request-grant-transmit cycle for more takes far less time.

Edited by XGS_Is_On (Thu 18-May-23 12:01:36)

In reply to a post by XGS_Is_On:

In reply to a post by Pyrrhic:

Thanks for explaining - that's good to know!

Welcome! On cable and RFoG networks before you can transmit you have to ask for permission and are given a set time period to send your data. That takes at least 2-4 ms depending on the timings set by the cable company. The time periods are in a message called the upstream MAP, and that's sent on the downstream to all devices in the segment at a set interval. The more often it's sent the more bandwidth the cable company loses to the overheads, but with the potential to provide lower baseline latency and jitter.

Also this comes with a loss of upstream bandwidth as there are 'contended minislots' in each message - these are where a modem sends its upstream burst to ask for slots to send data.

This all used to be a problem, actually, as the intervals limited the amount of times a modem could transmit but this was fixed through a combination of allowing modems to attach a request for more data to the last transmission they send, and through allowing modems to group a bundle of data into a single burst, filling empty spaces in the grant with small packets rather than one stream, one request, one burst.

https://people.computing.clemson.edu/~westall/851/do... is out of date now but still holds as far as BQM goes on RFoG - you have no DoCSIS 3.1 channel so it's basically the same as that PDF but on steroids.

Same story on PON networks actually however they both pre-emptively provide some bandwidth to each ONU and the request-grant-transmit cycle for more takes far less time.

Thanks! Crikey, it really is a lot more complicated than I expected.

I've started experimenting with switching my torrent box off 8am-8pm every day, and stability definitely seems to be up (less glitching on video calls) despite the downloader already being quite strongly limited during the day - have it set at around the equivalent of a tenth of my download and upload speeds. I also thought I was pretty strict in terms of max number of connections (200 I think?) but I think I might try tweaking that down as well in case the Eero router is getting overloaded.

In reply to a post by Pyrrhic:

Thanks! Crikey, it really is a lot more complicated than I expected.

I've started experimenting with switching my torrent box off 8am-8pm every day, and stability definitely seems to be up (less glitching on video calls) despite the downloader already being quite strongly limited during the day - have it set at around the equivalent of a tenth of my download and upload speeds. I also thought I was pretty strict in terms of max number of connections (200 I think?) but I think I might try tweaking that down as well in case the Eero router is getting overloaded.

So one thing stemming from what you've mentioned there - the torrents will be requesting the next load of bandwidth as they send the files, while a new flow like a video call might end up having to wait in your modem behind the torrents. Need to, if you're planning to run both at the same time, have some shaping on a router before it hits the modem. The torrent client might not be the greatest shaper.

Hopefully you aren't far from them getting XGSPON available to you. That'll mostly solve the issues immediately.

Interesting to learn new things, thanks.

In reply to a post by XGS_Is_On:

So one thing stemming from what you've mentioned there - the torrents will be requesting the next load of bandwidth as they send the files, while a new flow like a video call might end up having to wait in your modem behind the torrents. Need to, if you're planning to run both at the same time, have some shaping on a router before it hits the modem. The torrent client might not be the greatest shaper.

Hopefully you aren't far from them getting XGSPON available to you. That'll mostly solve the issues immediately.

Oh interesting! Do you mean something like quality of service? I actually have no idea what Eero offers in that regard. I'll look. I...feel super dumb for not even thinking to try that actually. 😁

EDIT: it appears to be a toggle called 'optimise for conference and gaming' in Eero labs, and I already had it switched on. Heck, maybe I'll try switching it off and see if things perversely improve...

Edited by Pyrrhic (Sun 21-May-23 10:41:48)