@nallar wrote:
This could be related to the sampling rate of the thinkbroadband graphs and some process on the hub occuring at intervals.
It's like the interference pattern of two waves with frequencies which are not quite the same.
https://www.wolframalpha.com/input/?i=sin(x)+-+sin(x*1.1),+sin(x),+sin(x*1.1)+from+0+to+32pi
If TBB pings every second exactly and the hub 3 has a latency spike every 1.1 seconds you would see a pattern a bit like this.
It could also not be anything like that at all and this entire post is a load of nonsense. 😄
Could well be, Ive long argued that the IRL experience of a HUB3 VS SH2AC is not as chalk and cheese as BQM's suggest. Dont get me wrong the PUMA6 chip-set is a POS, it needs binned. IMHO firmware aint gonna fix it.... BUT I've 2 semi-pro gamers (read 2 amateurs who think they're pro and complain about latency - joking guys I luvs ya really in case they are reading) and switching them between the two gives very few issues (Ive both up and running). You DO see substantial differences in throughput though with HUB3 being the worse of the two and it even seems to buffer-bloat worse.
To Kippers
Nice idea but possibly not
If it was a timing problem I feel it would be more even.
And here's my CMD ping run..notice that after a few quite high peaks it calms down. Again odd.
@wotusaw wrote:To Kippers
Nice idea but possibly not
If it was a timing problem I feel it would be more even.
Without going down the route of grandmother and suck eggs...
Compare your blue trace to the yellow trace. In areas where yellow declines, blue does not necessarily. So although Maximum latency (yellow) DECREASES, average latency (Blue) sometimes tracks yellow, but in a lot of cases DOES NOT= in fact INCREASES where max latency decreases.
Given we are attempting to track a latency increase due to a chipset issue, we SHOULD see (if timings lined up). average latency following maximum latency.
In theory, if timing lined up, Wave 1 (Base latency) +Wave 2 (chipset spike)=max latency- BQM plot would follow base latency.
As that's not happening and we KNOW the PUMA6 issue is regular as clockwork, its a fair assumption that the firebrick cycle being out of sync with the PUMA6 spike follows an interference pattern. As we have two waveforms (firebrick poll and PUMA6 spike) and we are measuring the COMBINED result (we can do no other using BQM as a measure)
In fact your PING run feeds into that, its a LAN side measure of ACTUAL effect of the PUMA spike, or if you prefer ONE of the waveforms a WAN side measure is attempting to plot.
You would need someone fully conversant with the math of the plots to PROVE thats the case, but given the only thing the firmware change is going to change is timings on the HUB, its a fair assumption all we are seeing is a change in interference pattern (one waveform has changed) especially given your average latency no longer tracks max latency. ANd that IRL results will be largely unchanged, which we know from the results of other PUMA6 firmware "fixes" - that it tinkers with ICMP timings, but HTTP and UDP are largely unaffected.
I phoned Virgin tonight to try and get them to activate my old super hub 2ac. Got told no we don't do that. Ended up speaking to someone else after I started to talk about this thread - possibly her supervisor as he spoke much better English. But again - he kept saying no we don't do that, we want all customers on superhub 3. He didn't seem to acknowledge the puma chipset problem and said once a superhub 2 has been deactivated they cant reactive...
I insisted he could based on what other people have written in this thread so he took the mac of the old hub and put me on hold. Came back to say the mac wouldn't register on the system...
BQM below
Red is me plugging in my old hub on the phone to them.
Should i keep trying to get them to activate?
@RockerSBM wrote:Hi All
My graph with the Hub3
cheers
shaun
That seems very quiet compares to mine, are you running in modem mode?
