50mbit question on ubr capacity and jitter

[Chrysalis]

Ok here is my query.

currently I am on 20mbit, ubr downstream capacity 36mbit means it cannot even handle 2 customers fully bursting at once, so if 2 customers burst at once latency shakes around etc.

Is 50mbit always serviced on a 200mbit downstream channel? meaning the effective contention ratio is lower and requiring 4 customers to max burst before jitter will appear, and what is the upload capacity like on the upstream channels used?

thanks

[Ignitionnet]

Downstream does take more customers to nosh all the bandwidth as there's 200Mbit available, upstream takes less as there's only one of them to each area that delivers slightly below 9Mbit of usable bandwidth and jitter will start around 6Mbit instead of 3 or 4 to the same node on the legacy network so if you're in a high usage area for upstream you're hosed.

Haven't been any issues with downstream utilisation that I've heard of, but a lot of issues with upstream.

[Sephiroth]

Igni, is it true that some areas have more than one upstream circuit going down the same street? In that scenario the house tap splits the frequencies and puts your upstream onto an upstream trunk, one per 200 yards (say), while the downstream trunk is common.

Does this happen anywhere and do you sort of know where if so?

[Ignitionnet]

Igni, is it true that some areas have more than one upstream circuit going down the same street? In that scenario the house tap splits the frequencies and puts your upstream onto an upstream trunk, one per 200 yards (say), while the downstream trunk is common.

Does this happen anywhere and do you sort of know where if so?

No, taps don't split frequencies they are passive and indiscriminate. This happens all over the network at the node level, the entire overlay network is built with a single bonded group spread across multiple nodes, for example 8 nodes while each 2 nodes have an upstream of their own physically separated right from node to port on CMTS card.

[Chrysalis]

interesting.

I see the docsis3 specs indicate a much higher upstream limit, so have VM rolled this out on the cheap then not doing full docsis3 spec? I think that might explain one of your posts I read somewhere about them not doing upload properly on the new network.

Apparently according to the tech that was here a couple of days back my ubr has a lot of students on it which could well explain why the 50mbit is also apparently bad (high upload on p2p).

In your opinion is the affect on a connection worse from downstream saturation or upstream saturation? At the moment we both believe my downstream is saturated, my upstream I dont know? could also be saturated, but if I moved to 50meg then my downstream is much more likely to be ok but then a upstream problem if I understand you correctly. Of course I know upstream saturation can kill download performance due to the acks getting dropped. :(

[Ignitionnet]

In your opinion is the affect on a connection worse from downstream saturation or upstream saturation?

Upstream has a far more profound effect on the connection than downstream due to how the bandwidth is allocated up and down.

[jrhnewark]

Upstream has a far more profound effect on the connection than downstream due to how the bandwidth is allocated up and down.This is the issue with a potential of 50Mbps downstream but only 1.5Mbps upstream... I say only 1.5Mbps upstream, any more and I'm sure VM know full well that with upstream channels shared that only have a total of 7/9Mbps total bandwidth you'll run into problems quite quickly.

If you've only got 500kbps upstream left on your bit of the network, you're not going to get steady 50Mbps downstream using TCP!!

I suppose VM being tight about their rollout of 50Mbps/DOCSIS3 is an accountant's decision, not a technical one, and to actually only let four customers onto each node would not make economic sense.

The question is, how many 50Mbps customers are they squeezing onto each node with only 9Mbps upstream?!

---------- Post added at 19:55 ---------- Previous post was at 19:33 ----------

Actually, Ignition's very interesting blog has explained all: We're talking 200Mbps downstream and 4 x 9Mbps upstream best case, however each modem is only able to use 1 of the 4 upstreams. This has resulted in congestion, some areas having just a handful of modems on an upstream while others that even share the same downstream bandwidth have 100 or more modems on an upstream.

Aye carumba! I think I'll stay on 10Mb!

[Chrysalis]

well I not sure what virgin media are playing at, granted wiki may be wrong but according to wiki only docsis 1.x has 9mbit upstream whilst docis2 has 27mbit a very significant improvement and docsis 3 should be able to do 4x27mbit so 108mbit of upstream bandwidth. So how VM got 108mbit down to 9mbit is incredible.

Meanwhile on my 20mbit I think I have saturated upstream and downstream even at 3.30am. Another post update on this in my congestion thread.

[broadbandking]

Remember the downstream is Docsis 3.0 but the upstream isn't

[Sephiroth]

Somebody will jump on me for the merest mistake!

The upstream channel bandwidth is 3.2 Mhz. This rate has been chosen by VM to reduce susceptibility to noise present at the lower frequencies, having particular regard for the state of VM's network. Currently upstream is served at QPSK (2 bits/symbol for bad line condition) or QAM16 (4 bits/symbol for less bad line condition).

The QAM16 symbol rate @ 3.2 MHz is 2.56 million/sec @ 4 bits/symbol = 10.24 Mb/channel upstream including overheads.

The downstream channel bandwidth is 8 Mhz (in most places). The downstream frequency spectrum is not immune from noise but that noise is induced by different sources from upstream. So higher bandwidth per channel and higher symbol rates are possible for downstream.

The 256QAM symbol rate @ 8 Mhz is 6.952 million/sec @ 8 bits/symbol = 55.62 Mb/channel downstream including overheads.

So we can immediately see why upstream comes down to 9 Mbps data rate on the VM HFC network and how roughly 6 users of 1,5 Mbps upstream capacity will saturate this provision.

Next, what can be done about it? Bonded upstream channels is a possibility; that would require every subscribing non-50 meg user to be given a new CM and cards in the UBRs will need to be upgaded to handle bonded upstream. Giving users, say 3 Mbps (for argument's sake) upstream reduces the number of users required to saturate the upstream at full data rate to 3. Back to square one in many areas of high two way traffic usage.

If the state of the HFC network can be improved, the upstream bandwidth could be upgraded to 6.4 Mhz, doubling the available data rate without changing modulation, but halving the number of users that can be squeezed onto a single channel. Again, not feasible under present upstream policies.

If the state of the HFC network can be improved, the upstream could be modulated at QAM64, staying at 3.2 MHz to maximize the number of concurrent users. The QAM64 symbol rate @ 3.2 MHz is 2.56 million/sec @ 6 bits/symbol = 15.36 Mb/channel upstream including overheads. This could push up the VM upstream offer to c. 2 Mbps upstream.

None of this overcomes the basic problem - which is that the available upstream frequency spectrum in Europe is 5 MHz to 65 MHz (I've not seen upstream allocated above 42 MHz but that's an observational thing). To overcome this, something fairly drastic needs to be done with the VM infrastructure (which won't happen IMO). For example, 4 upstream channels back to the CMTS frm the street cab with associated CMTS cards; or active tap points to bring more upstream channels down the street.

The stark fact is that BT's Infinity product, on the face of it, with FTTC and a totally different and less constrained/susceptible frequency plan, is a better proposition than VM cable.

We get FTTC in Wokingham later this year and if it comes to my locality, I'll move from O2 (if they are not able to offer > 24 Mbps) back to BT on my second broadband circuit. Then you'll have a horse with 2 mouths (if you don't think I'm one already!).

[Ignitionnet]

Next, what can be done about it? Bonded upstream channels is a possibility; that would require every subscribing non-50 meg user to be given a new CM and cards in the UBRs will need to be upgaded to handle bonded upstream.

Upstream bonding is, just like downstream bonding, backwards compatible, and existing overlay kit is capable with the appropriate software so no need for hardware swap.

If the state of the HFC network can be improved, the upstream bandwidth could be upgraded to 6.4 Mhz, doubling the available data rate without changing modulation, but halving the number of users that can be squeezed onto a single channel. Again, not feasible under present upstream policies.

Check out statistical contention (http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=statistical+contention).

This is doable in some areas, could even take another upstream from the legacy network to do it where there's lower utilisation on the existing network. It doesn't affect the number of users squeezed onto a single channel RF bandwidth is an issue at nodal level not at CMTS port level.

None of this overcomes the basic problem - which is that the available upstream frequency spectrum in Europe is 5 MHz to 65 MHz (I've not seen upstream allocated above 42 MHz but that's an observational thing). To overcome this, something fairly drastic needs to be done with the VM infrastructure (which won't happen IMO). For example, 4 upstream channels back to the CMTS frm the street cab with associated CMTS cards; or active tap points to bring more upstream channels down the street.

There are a number of areas that go to 50 and 65MHz upstreams, but a number that stop at 40 or 30. I am unsure what you mean about active tap points, the issue again lies at the node. Either too many homes to each node or bandwidth restrained nodes with optics and diplexer that restrict to a low band on the upstream direction.

No 'mere' mistakes but a bit of misunderstanding over where the crunch points lie and the logical and physical construction of the network, hope it's a bit clearer.

[Sephiroth]

......
No 'mere' mistakes but a bit of misunderstanding over where the crunch points lie and the logical and physical construction of the network, hope it's a bit clearer.

It's the only way to tease out the full story of how it works!

[Ignitionnet]

It's the only way to tease out the full story of how it works!

http://www.amazon.co.uk/Modern-Cable-Television-Technology-Communications/dp/1558608281/ref=sr_1_6?ie=UTF8&s=books&qid=1270375363&sr=8-6 is the only way to get the full story on how it works ;)

[speedfreak]

http://www.amazon.co.uk/Modern-Cable-Television-Technology-Communications/dp/1558608281/ref=sr_1_6?ie=UTF8&s=books&qid=1270375363&sr=8-6 is the only way to get the full story on how it works ;)

Far cheaper to keep getting info from you though :angel: :D

[Sephiroth]

Far cheaper to keep getting info from you though :angel: :D

If you can tease it out! :LOL:

[Chrysalis]

ahh ok so the downstream on the 20mbit ubr's is higher then I thought about 2.5 users worth of burst. eurodocsis I assume then 50mbit excluding overheads. However 2.5 users able to saturate their local node from where I sit is hideous and shows how fragile VM's local network is. If we compare to some adsl isp's they have users with average sync speeds of 4.5mbit sharing a gigabit backhaul from the exchange, that been 200 users to saturate the link vs 2.5 users (or 4 users on docsis3).

Seph's explanation of the upstream doesnt make sense to me, its as if VM are mixing a docsis3 downstream with a docsis1 upstream? what stopped them using a docsis3 upstream?

Also with VM now finally rolling out digital tv to analogue areas, can doing things like disabling the analogue tv provide extra bandwidth per ubr for broadband?

My feeling is to remove the fragility of the cable network VM either need to very significantly reduce amount of users per UBR (not going to happen I am realistic) or get the total capacity a lot higher so it takes at least at minimum 20 users to max out the shared capacity, which would mean 1000mbit downstream channel excluding overheads and 30mbit upstream, for 20mbit 400mbit downtream and 15mbit upstream.

[Sephiroth]

[QUOTE=Chrysalis;34994352].......

Seph's explanation of the upstream doesnt make sense to me, its as if VM are mixing a docsis3 downstream with a docsis1 upstream? what stopped them using a docsis3 upstream?
....QUOTE]
I'll just comment on the piece with my name against it other than to say agree with you on the fragility of VM's network.

They do mix DOCSIS 3 downstream with DOCSIS 1 upstream except in experimental areas where they have used DOCSIS 2 upstream.

I'm also sure that they didn't offer bonded upstream for the reason I gave - put into in other words, they need to eak out what they've got by way of channel capacity until they can sort their infrastructure.

Igni will almost certainly have a view.

[Chrysalis]

Thanks for clarifying that seph.