What could possibly have gone wrong?
 

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.

Re: What could possibly have gone wrong?
 

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

Re: What could possibly have gone wrong?
 

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.

Re: What could possibly have gone wrong?
 

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!!!

Re: What could possibly have gone wrong?
 

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.

Re: What could possibly have gone wrong?
 

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
http://www.thinkbroadband.com/ping/s...09-07-2012.png

mine
http://www.thinkbroadband.com/ping/s...09-07-2012.png

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
http://www.thinkbroadband.com/ping/s...06-07-2012.png

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 :dunce:

Re: What could possibly have gone wrong?
 

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)

Re: What could possibly have gone wrong?
 

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

Re: What could possibly have gone wrong?
 

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? :D

Re: What could possibly have gone wrong?
 

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

Re: What could possibly have gone wrong?
 

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

http://www.thinkbroadband.com/ping/s...10-07-2012.png

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.

Re: What could possibly have gone wrong?
 

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

Re: What could possibly have gone wrong?
 

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.

Re: What could possibly have gone wrong?
 

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

Re: What could possibly have gone wrong?
 

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).

Re: What could possibly have gone wrong?
 

They've only added downstream capacity, not upstream. Jitter on cable is a function of how the upstream works, and almost all the jitter on VM comes from upstream congestion.

Plus, adding more downstream capacity will increase the load on the upstream channels because of increased ACK traffic.

---------- Post added at 17:48 ---------- Previous post was at 17:46 ----------

Almost all jitter on VM is on the upstream. Upstream channel bonding has not been implemented yet.

---------- Post added at 17:53 ---------- Previous post was at 17:48 ----------

If you mean like this then that's simply a software change and part of how the supervisor modules in enterprise routers work, and nothing to do with network capacity or congestion.

Pretty much every ISP's core network is always like that. Core network problems are not only treated as some of the most serious fault types but are also often the easiest to fix.

Re: What could possibly have gone wrong?
 

wonder when they will start fixing the upstream issues
is so expensive to add one more upstream channel?

Re: What could possibly have gone wrong?
 

Upstream apparently does cost more than adding downstream capacity, but you'd think logic would prevail and they would actually upgrade upstream capacity accordingly to account for load?

Re: What could possibly have gone wrong?
 

sorry little off topic...well they don't understand they have problem?

Or when Bt will bring out next year FTTC on demand they will start again an other network updates so for an other 12 months will be unstable connections until they will finish work again by that time

why they just dont do now (which all ready started)a future work to last few years and stay in the competition for a good time

Re: What could possibly have gone wrong?
 

Because they are morons and they want their customers to move to BT Infinity.

I will gladly oblige when i move to Liverpool in a months time. I'm done with the sinking ship, HMS Virgin Media.

Re: What could possibly have gone wrong?
 

Hi again
Having now the r36 firmware it will not change other channels so you was right that your channels was limited
i have reset 7-8 times with r36 and will not change channels atoll
with r35 was so easy almost each reset will change
Not so sure about it

Re: What could possibly have gone wrong?
 

Err, babis3g. You didn't have R35, no one did. Your last iteration was R30 along with the rest of us :(

Re: What could possibly have gone wrong?
 

apologise , i mean r30

Re: What could possibly have gone wrong?
 

Have they actually got upstream bonding working in the Superhub firmware?

Has anybody actually got it - if so please post up a screenshot showing it.

Re: What could possibly have gone wrong?
 

Upstream bonding was only in use in test areas i believe.

Re: What could possibly have gone wrong?
 

I know they did some 200Mbps feasibility trials as somebody here was posting about them (roughbeast?) but they were not using a superhub so it doesn't answer the question.

Until they do get upstream bonding working I'm guessing they'll have to rely on the far less satisfactory solution of hoping that load balancing just done by putting a rebooting modem on the least busy upstream will be good enough. I seriously doubt that it will - the higher capacity a pipe has in relation to individual speeds it has to service the higher loading it can carry before it starts to creak. Two bonded 18Mbps channels are far better than two single 18Mbps ones. In fact I really can't see a single channel ever supporting 10Mbps upstream at the sort of contention ratios VM use without it being total dross.

Re: What could possibly have gone wrong?
 

Its working fine on the network, and on the superhub. The only problem with it is with the VMNG which needs a firmware update

Re: What could possibly have gone wrong?
 

Thanks for the info - seems I was too pessimistic....

Re: What could possibly have gone wrong?
 

Indeed, i've seen no evidence of the SuperHub ever having had problems with upstream bonding, it just needs to be enabled.

It just boggles the mind why VM leave the downstream in such a state.

Re: What could possibly have gone wrong?
 

I guess that you wouldn't see any problems if you've never seen it enabled :)


I'm pretty much certain they'd have problems with upstream bonding in my area - there's only the one channel that I've ever seen :(

Re: What could possibly have gone wrong?
 

I've seen it on community forums,

Re: What could possibly have gone wrong?
 

Yes craigs link showed stats which were originally posted on the community forum. It isn't common and I'd never seen it as I don't spend time on the VM community board unless I've got an open problem reported there - I just treat it as a TS resource where the TS replies extend past reboot the Superhub and your PC.

Re: What could possibly have gone wrong?
 

Seeing as that guys post was about only receiving 25meg down when he's on 100 and the reply from tech support was sorta cryptic, we dont know if the US bonding wasn't the cause.