Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[William Grimsley]

Not really no, for MDWS you really need a Broadcom DSL chipset. Cable isn't DSL.

Oh, yes. Thanks for confirming.

[niemand]

For most of the UK Virgin Media are their best chance of getting ultrafast speeds of any kind soon, and in most cases gigabit too.

[S.Stephenson]

For most of the UK Virgin Media are their best chance of getting ultrafast speeds of any kind soon, and in most cases gigabit too.

If DOCSIS 3.1 is all it promises to be even G.Fast looks G.Slow 

My experience with Virgin Media was positive apart from the annoying p2p traffic management and the halving of speeds when I actually needed it.

I think the pings were a bit high but the speeds of 100mbps were great, as I no longer play games online that require low pings i'd take virgin media if it was in my area in a heartbeat.

[Chrysalis]

someone is speculating VM are achieving this by deploying WFQ in congested areas to make small packets take priority.

[niemand]

Speculating they are achieving what, Sir?

[niemand]

If DOCSIS 3.1 is all it promises to be even G.Fast looks G.Slow 

3.0 is quite capable of seeing off even BT's longer-term plans for G.fast, let alone the 300Mb/50Mb it will apparently be launched at.

Comparing G.fast to DOCSIS 3.1 is beyond comedy.

[Chrysalis]

Speculating they are achieving what, Sir?

weighted fair queuing QoS, as their traffic pattern matches what that type of QoS does.
Check the thread on tbb.

So downloads start fast then the VM QoS slows it down.

[Chrysalis]

If DOCSIS 3.1 is all it promises to be even G.Fast looks G.Slow 

3.0 is quite capable of seeing off even BT's longer-term plans for G.fast, let alone the 300Mb/50Mb it will apparently be launched at.

Comparing G.fast to DOCSIS 3.1 is beyond comedy.

depends if you only care about access speeds or actual performance

Although I think g.fast is at risk of VM style congestion also.

[niemand]

Okay I'm lost so I'll try again: what are you saying WFQ achieves for VM?

You said:

someone is speculating VM are achieving this by deploying WFQ in congested areas to make small packets take priority.

So you have since said basically that WFQ achieves WFQ, not what the end result VM are achieving through it is.

That symptom by the way doesn't on its own indicate WFQ. Also happens with normal TCP congestion control on FIFO queues depending on how aggressively the TCP stack ramps up congestion window.

On the matter of G.fast being at risk of congestion, no more so than selling a gigabit via GPON.

[niemand]

http://www.thinkbroadband.com/speedtest/results.html?id=146152479122573813876



That's me forcing congestion, nothing to do with WFQ, just packets being dropped / sending speed slowing down due to congestion window filling.

The single flow was controlled, the multiple flow test had the pleasure of more bites at the bandwidth cherry.

Alongside TCP congestion control it's worth checking out TCP fairness. Even without any kind of external queuing multiple TCP flows achieve higher total throughput than a single flow in congested conditions. It's why P2P has always been the bane of every cable operator's life.

[Chrysalis]

I am not saying it, the guy on tbb is, I am just echoing his thoughts here.

[niemand]

I see.

WFQ on CMTS downstream interfaces works per DOCSIS service flow, not per IP flow. It is how Comcast, for example, do their 'Powerboost' - ERBA service flows. It doesn't care how many IP flows are opened in each service flow and works to provide fairness between modems and try and combat the P2P effect I mentioned.

Hope that helps.

Edit: With regards to smaller packets remember what downstream format DOCSIS has - MPEG 2 frames. Smaller IP packets are handy to avoid wasting bandwidth on padding.

I can't say for sure VM aren't using it but, certainly, there are other explanations and if anything the behaviour suggests they aren't. If they were the additional TCP flows would, I would have thought fail to draw more bandwidth.

If they are, good. Fairer bandwidth allocations during congestion periods is a good thing.

That said I am no QoS expert. It's a field all of its own. Discussed by people way smarter than me.

[Chrysalis]

I sort of agree also, whilst I think VM really need to get on top of capacity, prioritising small packets is preferable to alternatives.

Ironically a property I am thinking of moving to in a better area I checked today is a choice of 2mbit adsl or VM.

But since its way outside the city, I assume VM wont be congested.

[niemand]

Okay think I understand what you meant it was there to achieve.

If WFQ is deployed it's platform-wide and part of a standard configuration.

The only time any specific configuration was applied to congested areas was when Telewest enabled STM on the quiet in some a while ago.

[Weaver]

No matter how much capacity - link throughput capability- you have, there will always be a need for QoS prioritisation for certain services surely. There will be occasions where a group of users can max the link usage out with a lower priority kind of traffic.