Quote:
Originally Posted by MUD_Wizard
Bear in mind that the Thinkbroadband BQM graph samples 100 seconds worth of pings. The minimum, average and maximum are calculated from that.
So on the maximum you could have 99 seconds of 20ms pings and one second (or fraction of a second) of 100ms ping, and that would produce the yellow spikes in the graph you see.
The Superhub2/2ac also produced similar levels of 100ms spikes, though not as often. If you keep in mind that someone on 16 channels has two sets of 8 channels, then two sets of 100ms spikes would look like the graph we're seeing.
If you run a continuous ping to google you will notice a few 100ms pings mixed in with 99% around 20ms.
The latency shown on speedtest.net and pingtest.net tests aren't maximum latency, but average latency (represented in blue on the BQM). Which is why it won't show up there.
|
This confuses me. The jitter doesn't come from downstream, it comes from upstream. Virgin Media's measured jitter downstream is actually pretty good.
Adding more channels should help with any latency issues on downstream, not hinder them. They aren't considered 2 blocks of 8 channels but 1 block of 16 and the scheduler should use the least loaded channel when deciding which channel to send traffic down. The scheduler has full control over the loading of channels and can easily ensure no channel sees 100ms of queuing.
Sure this isn't just something alongside the same lines as why people are reporting higher baseline minimum latency on this kit, it's a little tardy about responding with the existing firmware?
Nothing wrong with that, mind you.
---------- Post added at 01:12 ---------- Previous post was at 01:10 ----------
Quote:
Originally Posted by MUD_Wizard
No, it's what I expected for 16 channels.
People who've shown BQM graphs from Hub 3's on 8 channels looks roughly the same as a SH2/2ac BQM.
|
If that's the case there are definitely some issues to fix. That really shouldn't happen.