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)