Superhub What could possibly have gone wrong?

boroboi · 09-07-2012, 17:49

Just a speculation thread really, because it's a bit annoying and i'd like to just discuss it a little.

I was on the Superhub which was a jittery bugload of poop. I then went over to the VMNG300 which was fine, but the weekend of the R36 trial, jitter began to affect that also.

So hence forth re-activation of the SuperHub... as i was part of the R36 trial, i just asked Mark Wilkin to pop it over and he did so, to which jitter was the best i've ever seen it.. i.e. hovering at 0 and occasionally maxing out at 2.

Wednesday morning last week upgrades took place in my area with regards to the double speed upgrades, i went from 4 channels to 6 and ever since then, all improvements i saw with the R36 firmware have been negated, jitter is back to it's original ridiculousness and even the VMNG300 is the same... so what the hell have they done?

What could they have done during the upgrade to completely wreck the latencies? I'm at my wits end now.

babis3g · 09-07-2012, 17:59

i think it also de-pence what downstream and upstream channels will lock
Some channels are more congested
when i will come back as for proof (got to go now) i will post a graph with mine and a mate just 2 doors next of me being on the same cable

boroboi · 09-07-2012, 18:02

That's the whole point of channel bonding though, congestion affects you less when you have more channels to balance the load.

As for upstream congestion, it's possible but i don't see how it could be considering it was completely fine before the upgrades, i've tried both upstream channels available to me and both are exactly the same.

Something has definately been bodged during the upgrade, there is no other reason for it to be fine before and then a complete mess afterwards.

boroboi · 09-07-2012, 23:09

Just been running some tests, and it appears that the core node is completely to fault.

I am pinging the first hop of my connection, core node midd-core-2b-ae3 with IP address 213.106.236.89, every 50ms, with a minimum latency of 7ms. The latency is all over the place spiking as high as 40, with an average latency of 12, this produces jitter into the double figures, around 10 or 11ms JUST AT THE CORE NODE!!!

boroboi · 10-07-2012, 01:11

Update*

I'm now monitoring both the CMTS and the Core node from TBB and the latencies, bar a spike on the core node, appear to be perfectly fine, so the cause of the jitter is between myself and the CMTS it seems...

So what piece of hardware could possibly cause jitter on an inactive connection, between my Superhub and the CMTS? Pinging the Superhub itself on the internal network results in <1ms, so the hub itself at least on my end is reporting stable.

If a mod could merge these last 3 posts into one, that would be great. I can't edit them myself.

babis3g · 10-07-2012, 01:28

Back from work now
Here my case but with r30 firmware (but i am sure still apply to the r36)
What i mean with every firmware if find a less congested channel i m sure can get less jitter
Both with 5 channels (as you say which helps of course) but apart that the channels the modem locking it helps more

mate next door(yesterday graphs)
bear in mind he got 4 laptops and few phones plus xbox (maybe that why to high spikes in a small connection
He is on the same cable,cabinet but locked to different down/up channels than me

mine

Now before 3 days got about 6-7 disconnections in sort time,due to T3 errors which cost in return reset to my SH
(is coming an engineer about it)
(dont know if affected mate next door because i set up his monitor day after)
The reset caused to change the bonded channels so each time the SH locked to different one
Note about 5:15 till about 5:45 it locked to one with bigger jitter spikes
I done test via pingtest.net and jitter was 5 (now is all the time 2)
Also note my mate graph same time (even if is different date)
My SH locket to more congested channel as him

So i think that what happens to you
each time the SH get reset it change its values
Just reset it as many times need to find less congested channels

boroboi · 10-07-2012, 01:37

The downstream channels all remain the same, they don't change with resets, but the upstream... i have two channels available and i've tried both, it's exactly the same. Previously there was always one channel which was more congested than the other but now it just makes no difference what so ever. The jitter is mainly caused by the upstream in congested areas, as even ofcom can prove that Virgins downstream is perfectly fine, unfortunately ofcom also gave Virgin Media the title of worst for upstream jitter of any ISP.

As you can see in my last post though, the network upgrades appear to have done their job because the CMTS is actually 100% better than the last time i monitored it, now it doesn't even spike... and since the CMTS is the first point of access between myself and the rest of the VM network, there would appear to be something in the way that is artificially causing jitter on my line, and i'd like to know what that is and get VM to fix it if possible.

Could it be the optical node? is there anything in the cabinet which could be damaged or not working correctly? (the latter i doubt very much but thought id ask anyway)

babis3g · 10-07-2012, 01:41

Thanks for reply
I can tell 100% sure my downstream channels was changing each reset...i checked the modem each reset... plus my upstream changed but not all resets
The monitor is my proof...lol...tried hard to get some one at same cable to get an other monitor

boroboi · 10-07-2012, 01:44

It's strange that you would get changing downstream channels, i don't think i've ever heard of anyone being able to change them with resets, you would be the first, odd...

Well the monitor just shows that the modem was reset, i've seen similar changes in the past when i've switched upstreams, but not quite as noticeable since your graph is practically one of the best i've ever seen after your resets, can i move in with you?

babis3g · 10-07-2012, 01:48

and yes i have seen i VM forums more and more having reboots and resets so i think is their network (node,ubr,slot duno so expert stuff) and not my end
Wensday is coming an engineer so will see what will say about it

---------- Post added at 01:48 ---------- Previous post was at 01:45 ----------

here you go
when will face disconnection/reset again i will post here
i will had done a reset tonight but this channel or what ever cost lower jitter/latency is perfect so i dont at the moment .... forgive me...

Connection

Startup Procedure
Procedure Status Comment
Acquire Downstream Channel 323000000 Hz Locked
Connectivity State OK Operational
Boot State OK Operational
Configuration File OK
Security Enabled BPI+
Downstream Channels
Lock Status Modulation Channel ID Max Raw Bit Rate Frequency Power SNR Docsis/EuroDocsis locked
Locked QAM256 53 55616000 Kbits/sec 323000000 Hz 7.1 dBmV 40.3 dB Hybrid
Locked QAM256 49 55616000 Kbits/sec 291000000 Hz 8.1 dBmV 42.2 dB Hybrid
Locked QAM256 50 55616000 Kbits/sec 299000000 Hz 7.8 dBmV 42.0 dB Hybrid
Locked QAM256 51 55616000 Kbits/sec 307000000 Hz 7.6 dBmV 41.4 dB Hybrid
Locked QAM256 52 55616000 Kbits/sec 315000000 Hz 7.2 dBmV 41.2 dB Hybrid
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown
Upstream Channels
Lock Status Modulation Channel ID Max Raw Bit Rate Frequency Power
Locked ATDMA 5 20480 Kbits/sec 35800000 Hz 43.5 dBmV
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV
Primary Downstream Service Flow
Downstream(0)
SFID 1918
Max Traffic Rate 111000000 bps
Max Traffic Burst 10000 bytes
Mix Traffic Rate 0 bps
Primary Upstream Service Flow
Upstream(0)
SFID 1917
Max Traffic Rate 5120000 bps
Max Traffic Burst 16320 bytes
Mix Traffic Rate 0 bps
Max Concatenated Burst 16320 bytes
Scheduling Type Best Effort
Current System Time:Tue Jul 10 00:45:55 2012

EDIT when 5:15 reset again the 50 / 299000000mhz channel was locked at Acquire Downstream Channel

boroboi · 10-07-2012, 01:50

Im not sure if it's their network or not.. i mean, previously i've had a TBB graph up at my CMTS and it's been all over the place... but look here

I know its nearly 2 in the morning, but there is not one bit of inconsistency...

yet, i can ping that CMTS and get spikes into 40 and a constant jitter of 10 or more, i don't see how that makes sense at all, and since the CMTS is basically my entrypoint into the VM network, then there must be something between myself and the CMTS which is fobbing me off. The cause of the jitter isn't the CMTS or the Core node.

** no, no, please don't ruin your connection just to prove apoint... id love mine to be like that, at least i might be able to game on it instead of just looking at my console or shortcuts on my desktop and going... nah *sigh*

Thats odd, your max traffic burst rates are larger than mine on both up and downstream.

babis3g · 10-07-2012, 02:03

Just remember
here got it since T3 errors appears to my line from VM forum few weeks ago
my thread here still up to date
http://community.virginmedia.com/t5/...t/td-p/1246849

Connection

Startup Procedure Procedure
Status CommentAcquire Downstream Channel 299000000 Hz Locked
Connectivity State OK Operational
Boot State OK Operational
Configuration File OK
Security Enabled BPI+
Downstream Channels Lock Status Modulation Channel ID Max Raw Bit Rate Frequency Power SNR Docsis/EuroDocsis locked
Locked QAM256 50 55616000 Kbits/sec 299000000 Hz 1.3 dBmV 41.6 dB Hybrid
Locked QAM256 49 55616000 Kbits/sec 291000000 Hz 1.6 dBmV 41.5 dB Hybrid
Locked QAM256 51 55616000 Kbits/sec 307000000 Hz 1.3 dBmV 41.2 dB Hybrid
Locked QAM256 52 55616000 Kbits/sec 315000000 Hz 0.8 dBmV 40.8 dB Hybrid
Locked QAM256 53 55616000 Kbits/sec 323000000 Hz 0.4 dBmV 39.9 dB Hybrid
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown
Upstream Channels Lock Status Modulation Channel ID Max Raw Bit Rate Frequency Power Locked ATDMA 5 20480 Kbits/sec 35800000 Hz 52.0 dBmV
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV
Primary Downstream Service Flow Downstream(0) SFID 362 Max Traffic Rate 111000000 bps Max Traffic Burst 10000 bytes Mix Traffic Rate 0 bps
Primary Upstream Service FlowUpstream(0) SFID 361 Max Traffic Rate 5120000 bps Max Traffic Burst 16320 bytes Mix Traffic Rate 0 bps Max Concatenated Burst 16320 bytes Scheduling Type Best Effort
Current System Time:Tue Jun 05 02:40:08 2012

EDIT the difference in power levels is because had T3 errors again few and engineer add me a special amplifier thats why now are higher with in limits but still T3 errors

qasdfdsaq · 10-07-2012, 09:38

Quote:

Originally Posted by boroboi

there must be something between myself and the CMTS which is fobbing me off. The cause of the jitter isn't the CMTS or the Core node.

Of course there is, that's called congestion, and the very nature of how cable works.

The bit between yourself and the CMTS is shared between thousands of other users.

boroboi · 10-07-2012, 14:53

Quote:

Originally Posted by qasdfdsaq

Of course there is, that's called congestion, and the very nature of how cable works.

The bit between yourself and the CMTS is shared between thousands of other users.

That just it, they've just upgraded capacity so i was hoping there was another reason for it

Eeeps · 10-07-2012, 15:20

On the original question about how more channels can lead to higher jitter...

Could be that they peformed some channel load balancing when they added the extra channels. Some of the folks sharing your cable segment have probably got much better broadband connections now.

Regarding the cause of jitter...

On the downstream jitter is caused by the buffering of packets in the CMTS because other users packets are waiting to be transmitted on your channels (or indeed your own packets if you are receiving more than your bandwidth provision).

Upstream jitter can have numerous causes but typically result from the delays in the granting of data transmission opportunities by the CMTS. These occur when all available upstream slots are being used by other modems (or your modem is attempting to exceed the provisioned transmission rate).