Small Download Speed Upgrade

[Ignitionnet]

Just to let those interested know VM are currently slightly upgrading the 100Mb service, this is so that you can reach 100Mb speeds after overheads on the connection.

At the moment the service is capped to 102.4Mb, leaving people reaching about 98Mb best case, due to new regulations coming in next year 10% of customers must be able to reach the appropriate throughput for a service to be advertised at that speed.

VM evidently didn't fancy selling 100Mb as 98Mb so they're increasing the downstream cap from 102.4Mb/s to 110Mb/s giving people about 105Mb/s.

It's quite common among cable companies to do this, it's called adding 'fluff'. A number of operators cap around 10% higher than the provisioned rate, VM are joining them.

Probably safe to assume 10Mb and 20Mb will receive caps of 11Mb and 22Mb, 30Mb is already capped at 33Mb, 50Mb is already capped at 53Mb and is receiving a different upgrade.

[ileikcaek]

Seems pretty fair to me! The 33Mb cap on 30Mb is good as it is, most get at least 31Mb (I've never dropped below it) from what I've seen in speed test results.

[BenJSmyth]

When does this take effect from and where did you get this info?

I'm intrigued :)

[AndyCalling]

What 'different upgrade' is the 50meg service receiving?

[Chrysalis]

My guess 80mbit/sec or around that bit.

VM seriously going to the "I dont care" on oversubbing.

---------- Post added at 21:55 ---------- Previous post was at 21:51 ----------

Seems pretty fair to me! The 33Mb cap on 30Mb is good as it is, most get at least 31Mb (I've never dropped below it) from what I've seen in speed test results.

Lucky you.

I havent been able to get 31mbit outside of 4-10am for about 2 weeks.

Hard to say if most get 31mbit/sec. I dont think any data out there for that, the latest samknows figures also really need an update as was before 100mbit launched.

[Ignitionnet]

When does this take effect from and where did you get this info?

I'm intrigued :)

They've started the rollout already, and dream on ;)

---------- Post added at 21:56 ---------- Previous post was at 21:56 ----------

What 'different upgrade' is the 50meg service receiving?

I could tell you but then I'd have to kill you.

---------- Post added at 21:57 ---------- Previous post was at 21:56 ----------

My guess 80mbit/sec or around that bit.

VM seriously going to the "I dont care" on oversubbing.

No and no respectively - this is the main driver for the moves to 8 downstreams.

[Chrysalis]

Not sure how you can say no to my 2nd comment, as VM have a poor record for dealing with congestion, so for you to say no to that would mean VM doing a policy shift. Planning for 8 downstreams is just PR talk at this time, given how long its taking to even get every area to 5 downstreams never mind 8, 8 could be years away.

[Ignitionnet]

Not sure how you can say no to my 2nd comment, as VM have a poor record for dealing with congestion, so for you to say no to that would mean VM doing a policy shift. Planning for 8 downstreams is just PR talk at this time, given how long its taking to even get every area to 5 downstreams never mind 8, 8 could be years away.

I can say no quite easily, I just know stuff and increasing oversubscription rates can be mitigated in a number of ways, both controlling supply of bandwidth and demand. You also forget that downstream upgrades don't go anywhere near the level of increased usage that upstream upgrades bring, there's only so much to download.

4 -> 5 downstreams is a far more complicated job than 5 -> 8. It needed line cards to be replaced in the case of BSRs and a shift to I-CMTS architecture in a number of cases on the Cisco.

I would recommend looking at how the line cards are broken down, multiples of ports per line card, etc, it would make more sense than assuming that the line card replacement required to go from 4 to 5 or in the case of many Cisco 10ks even just 3 to 4 downstreams is replicated in going to 8.

I'm not aware of it being PR talk, I've not seen VM make big news of this. Beyond us nerds no-one really gives a monkey's about how many downstreams VM are using in each service group.

[kwikbreaks]

increasing oversubscription rates can be mitigated in a number of waysThe most certain mitigation is the one I'll be using as soon as I can - Infinity. As far as I'm concerned they've blown it as far as my custom goes. Only question is whether I'll wait for Infinity or move to Be on ADSL before it comes.

[Ignitionnet]

That's certainly one option for people. I would suggest a combination of capacity upgrades and traffic management however are VM's ways forward.

[Billy-Bob]

My guess 80mbit/sec or around that bit.

At the risk of attracting the ridicule of some of the know-it-alls on this forum, this is precisely what I have been experiencing consistently on my 50Mb connection now for the last 10 days. I have cleared my browser cache, rebooted my modem on multiple occasions, and tried a variety of methods to measure my download speed - which is coming out at a rather more variable than usual 50-75 Mb/s. The config file still says limited to 53000000 downstream, but that isn't what I'm getting. So either VM have a fault on their rate-limiting system, or something else is going on.

[morley04]

Could you give us a clue to what the 50mb upgrade will be:erm:? or is it STM time for us guys:rolleyes:

[Ignitionnet]

At the risk of attracting the ridicule of some of the know-it-alls on this forum, this is precisely what I have been experiencing consistently on my 50Mb connection now for the last 10 days. I have cleared my browser cache, rebooted my modem on multiple occasions, and tried a variety of methods to measure my download speed - which is coming out at a rather more variable than usual 50-75 Mb/s. The config file still says limited to 53000000 downstream, but that isn't what I'm getting. So either VM have a fault on their rate-limiting system, or something else is going on.

No ridicule here!

The config files will change when it's time. Unsure why you're getting close to 80Mb but that is not the uplifted speed.

[morley04]

So theres an uplifted speed increase:shocked:

[ileikcaek]

Kinda hoping for a slight bump on 30Mb but I think that is less likely with most 30Mb customers being ex 20Mb customers and that was a "free" upgrade minus the £30 activation/superhub fee. Still a bump to 40Mb would be nice! I guess people in the know cannot say too much, like usual, there's probably an NDA on the upgrades VM are doing.

[morley04]

It would be nice to see a little increase of some sort hopefully they wont take months to roll these new config files.

[Rob King]

i got 100mb but really get over 97 mb on speed tests

[Ignitionnet]

Kinda hoping for a slight bump on 30Mb but I think that is less likely with most 30Mb customers being ex 20Mb customers and that was a "free" upgrade minus the £30 activation/superhub fee. Still a bump to 40Mb would be nice! I guess people in the know cannot say too much, like usual, there's probably an NDA on the upgrades VM are doing.

Be a tad more than a 'slight bump'.

You get nothing as part of the smaller increases as the 30Mb already has 10% on it, but do look forward to a speed increase next year :)

---------- Post added at 21:00 ---------- Previous post was at 20:58 ----------

i got 100mb but really get over 97 mb on speed tests

Which is exactly why VM are pushing the rate cap from 102.4Mb to 110Mb, you will see over 104Mb after.

[morley04]

So will 50mb see an increase next year aswell ? Im just hunting for answers as im bored at work.

[General Maximus]

great, i could have kept my vmng300 and had a free speed boost that worked :spin:

[Skie]

I can see them turning 100meg into something silly (150/15?) to one-up Infinity and 50meg turn into something that matches Infinity.

[morley04]

I think 50 will just see the 10% fluff on top so instead of 53mb max it will be 55mb I suppose unless they have some tricks up there sleeve

[kwikbreaks]

Ignore DOCSIS1 (10 +20) because VM do and you have...

33Mbps nnMbps 104mBPS with nnmBPS costing ~ £7.50 more than 33 and £10 less than 104.

To coin an (idiot) phrase - do the math.

Currently 50Mbps is poor value over 30Mbps imo and if 30Mbps had been announved at the time I'd have taken it when upgrading from 20 rather than upgrading to 50Mbps.

I'd far rather they sorted out the oversubscription issues than pushed headline speeds higher. I was told that my area upgrade was complete but almost immediately it became just about as bad as before - a single 100Mbps high volume user can easily stuff up the current low capacity local pipes. I'm obviously no network genius but I think if asked I could have predicted that no sanctions, unlimited 100/10 on 200/18 pipes would lead to this in some areas. I'd just have hoped I didn't live in one but sadly I do.

[Ignitionnet]

So will 50mb see an increase next year aswell ? Im just hunting for answers as im bored at work.

50Mb is already capped at 53Mb and is receiving a different upgrade.

[General Maximus]

I'd far rather they sorted out the oversubscription issues than pushed headline speeds higher.

You should come and live in my area dude, when I rang up the other day they said the utilisation on my UBR was negligable and I was the only 100mbit user on it (not that I believe them) but perhaps that is why I have always got my max speed (up and till now :D )

I can see them turning 100meg into something silly (150/15?) to one-up Infinity and 50meg turn into something that matches Infinity.

it would be nice if they made them 80/8 and 150/15, it ain't gonna happen though. I can see it going to 60/6 to make it more of a jump from 30 but still significantly less than 100

[kwikbreaks]

I can see it going to 60/6 to make it more of a jump from 30 but still significantly less than 100
That would be the sort of increase I'd expect to see. You're lucky that your area isn't busted - around here you'd probably only get the 10Mbps I downgraded to regardless of which on you picked. I guess they'll sort it out eventually but their track record on theses issues isn't good.

[Ignitionnet]

Just to clarify 100Mb is not getting uplifted to anything bar the 110Mb downstream to give extra fluff for overheads, so no point in speculating on what it may or may not be going to :)

All other tiers, however ;)

[General Maximus]

I wonder how much fluff you could download in a day with an extra 10mbits?

[Jayster]

I am guessing upstream is left out in the cold as normal?

[morley04]

Is there a time frame for these minor updates ? :monkey:

[Synthetic]

A bit of upload fluff would be nice too, only ever hit 9Meg up on our 100meg connection, but its good we're getting the extra 10Meg down :D

[crazyronnie]

Is there a time frame for these minor updates ? :monkey:

I think it will happen once VM has rolled out 100mb to all remaining areas.

[Chrysalis]

I can say no quite easily, I just know stuff and increasing oversubscription rates can be mitigated in a number of ways, both controlling supply of bandwidth and demand. You also forget that downstream upgrades don't go anywhere near the level of increased usage that upstream upgrades bring, there's only so much to download.

4 -> 5 downstreams is a far more complicated job than 5 -> 8. It needed line cards to be replaced in the case of BSRs and a shift to I-CMTS architecture in a number of cases on the Cisco.

I would recommend looking at how the line cards are broken down, multiples of ports per line card, etc, it would make more sense than assuming that the line card replacement required to go from 4 to 5 or in the case of many Cisco 10ks even just 3 to 4 downstreams is replicated in going to 8.

I'm not aware of it being PR talk, I've not seen VM make big news of this. Beyond us nerds no-one really gives a monkey's about how many downstreams VM are using in each service group.

Theres your mistake.

People on 100mbit can find enough to download to keep it busy pretty much 24/7. Tons of media content out there. Given it only takes 1-2 in any given area to cause problems its quite easy to see the serious misjudgement thats occured.

Next year when the xbox 720 is released microsoft whispers are the games will be download only no physical media, games I expect will be 10-40gig in size on average, demos will likely be at least half that size as well. But in terms of media currently available there is raw bluray been released multiple times a day at 40+ gig a pop very capable of keeping 100mbit lines busy.

Someone with your experience not only should think usage will increase, they should expect it.

Incidently VM have now officially confirmed downstream is "very highly" utilised in my area and its finally been escalated.

I remain curious of course on what 50mbit is getting of course and its good the fluff is been added in regards to complying with regulation but at the same time I feel my concerns are very valid.

[Ignitionnet]

Right, clearly there are people who have the storage and indeed the will to download 30TB/month.

It's no mistake it's a combination of common sense and fact. A 100Mb line pulls 1TB/day, over 20 full Blu Rays, even storing these on optical media would be impractical. Of course there's sufficient content to download 30TB/month, one could just re-download the same file over and over again all month, does this seem likely?

I fully expect usage to increase I'm not naive I just think, as usual, you're hijacking a thread because of your own service issues and with that in mind will not respond to further posts from you in this topic.

[kwikbreaks]

IMO Chrysalis is perfectly right - VM need to concentrate more on alleviating oversubscription by whatever means works and I expect that will be traffic management rather capacity increases. "Adding fluff" and increasing XXL speeds to bring them closer into line value wise with XL and 100 is purely for marketing purposes.

Oversubscription has moved me from happy bunny to definitely a lost customer long term (when I can get Infinity) and quite probably a lost customer immediately to Be ADSL once I've looked at the costs involved - this following a supposed upgrade which still leaves my CMTS oversubscribed by my definition but not VMs.

[greyhairbadger]

Hi,

Sorry to be a bit thick, but I figure if I don't ask, I won't find out:

What is the nature of the overhead?

I presume 102.4 Mbps is raw data rate, and 98 Mbps represents the encoded ethernet packets (frames? datagrams?)
If so, what is in the 4.4 Mbps? and is it encapsulated? Is it associated with the modulation / demodulation process?

Or am I barking up the wrong tree entirely?

Phil.

[Ignitionnet]

IP and TCP headers Phil, 40 bytes per 1500 byte IP datagram leaving 1460 bytes for usable data.

[greyhairbadger]

Oh.

Cheers Ignition. I was hoping it might be more interesting than that!

:)

Phil.

[roughbeast]

Download speeds of over 100Mb (110mb), including the fluff on top, would at the moment be pandering to a completely unnecessary arms race.

It will take some time for video, game and data technology to catch up with 100Mb, let alone 200Mb or 400Mb+. If commerce really needs that much they can get it now anyway. It will be some time before all but the most BB hungry student houses will need even 100Mb.

I agree with all those who say that from now on ISPs should concentrate on increasing capacity and moving towards connections that are more symmetrical. e.g. 10:3 would be fine for most of us. Quality of service should now be the mantra. VM needs to take that on board or become 1st choice only where they are the only choice.

[Ignitionnet]

It's nothing to do with an arms race it just relates to how the products are advertised. The rules are being changed so that ISPs can only advertise the speed 10% of their customers can achieve.

Without the fluff people can't get 100Mb throughput.

As far as the rest goes 100Mb is not getting upgraded to 200Mb any time soon so no worries there. 200Mb as a new tier around Olympics time.

[kwikbreaks]

200Mb as a new tier around Olympics time.Perfect for scrubbing any benefit from 8 downstreams and of use only to those addicted to downloading by the TB daily. Oh - and the marketing wonks.

[Ignitionnet]

Traffic Management v2 will deal with that.

[Chrysalis]

Perfect for scrubbing any benefit from 8 downstreams and of use only to those addicted to downloading by the TB daily. Oh - and the marketing wonks.

heh you read my mind, I guess those who get the 8 channels last will probably get just in time for 200mbit.

Dissapointed ignition now wants to ignore my posts, and traffic management v2 may deal with it better than whatever is in place now but at the same time traffic management shouldnt replace capacity, it should only complement it.

In terms of storage the content will either get trashed or burnt to removable media. Some people download and burn all day long.

[Jayster]

Any info on "Traffic Management v2"?

[roughbeast]

heh you read my mind, I guess those who get the 8 channels last will probably get just in time for 200mbit.

Dissapointed ignition now wants to ignore my posts, and traffic management v2 may deal with it better than whatever is in place now but at the same time traffic management shouldnt replace capacity, it should only complement it.

In terms of storage the content will either get trashed or burnt to removable media. Some people download and burn all day long.

I reckon some people are actually magpies who download and burn all day long, but actually they transfer their largess to the cloud because they can. They then say that they have a massively awesome collection of music and films in the cloud which they never watch or listen to. However, this is cool because wow it's awesome man. Bring on 400mb/40mb man.

[General Maximus]

Is there a time frame for these minor updates ? :monkey:

I would like to know that as well because although p2p traffic management should be in effect on all tiers, i tried it for the first time last night and had no probs whatsoever whereas on 50mbit it would crawl to a halt on Saturday evenings.

My guess is that we are going to be screwed and the previously non-stm'd 100mbit will be stm'd, they did the same once they had rolled out and got everyone on to 50mbit

[kwikbreaks]

Traffic Management v2 will deal with that.Bring it on although I suspect there will be much wailing and gnashing of teeth when it does arrive if it actually works unlike the POS they currently have in place which is so easy to circumvent. Perhaps as the Generalissimo suspects it will be a simple byte count and cap arrangement - if so and they really want to sort out oversubscription it will need to be a lot more aggressive than now.

[Ignitionnet]

Combination of byte count and port load, with progressively more aggressive penalties as high usage continues. In other words once degraded if you keep caning it for all it's worth you experience further degredation ;)

[kwikbreaks]

So is that goodbye to the already dishonest "unlimited" advertising?

[philwhite100]

I think it is far too easy to start faulting VM for their services. Surely other providers are not perfect either and by simply leaving one provider to go to another is not the answer.

I'm sure VM don't want to lose customers as with any company but quick fixes to issues you may have are rare with any provider.

[Ignitionnet]

I think it is far too easy to start faulting VM for their services. Surely other providers are not perfect either and by simply leaving one provider to go to another is not the answer.

:confused:

So rather than voting with his wallet he should just continue to pay for a substandard service?

Just as well most people aren't such subservient customers, operators would have zero incentive to supply decent services.

Of course no service is perfect but imperfect and unusable are very different things.

VM have never matched the stability or latency I achieved with ADSL, they only win for download speeds, indeed I ditched a 50Mb cable service mid-way through contract for a 16Mb ADSL service due to VM's inability to provide a stable service. I would be unlikely to be with them now if it weren't for that I'm unable to take Sky here.

It is both desirable and essential that consumers punish companies that supply substandard service by taking their business elsewhere.

[Jayster]

Combination of byte count and port load, with progressively more aggressive penalties as high usage continues. In other words once degraded if you keep caning it for all it's worth you experience further degredation ;)

Got any sort of figures, will the limits be similar to the current stm. Will it coexist with NNTP and P2P throttling?

[HD Boy]

Speed Upgrades.

This is my guess

10MB > 20MB
30MB > 40MB
50MB > 60MB
100MB stays the same
New tier of 200MB in 2012

[Skie]

Hopefully they will get rid of the P2P/NNTP throttling and just rely on the new traffic management. The P2P stuff has been constantly interfering with things it shouldn't.

But hopefully they do the sensible thing and do it entirely based on local needs and not just a hard limit nationwide. Some areas are capable of handling much more than others, and the current system has shown its not very effective to just have one rule for everyone. But I did say sensible and we are talking about virgin here..... :)

[Ignitionnet]

Speed Upgrades.

This is my guess

10MB > 20MB
30MB > 40MB
50MB > 60MB
100MB stays the same
New tier of 200MB in 2012

1 out of 5.

---------- Post added at 20:24 ---------- Previous post was at 20:23 ----------

Hopefully they will get rid of the P2P/NNTP throttling and just rely on the new traffic management. The P2P stuff has been constantly interfering with things it shouldn't.

But hopefully they do the sensible thing and do it entirely based on local needs and not just a hard limit nationwide. Some areas are capable of handling much more than others, and the current system has shown its not very effective to just have one rule for everyone. But I did say sensible and we are talking about virgin here..... :)

Yes and yes respectively! :)

[kwikbreaks]

Some areas are capable of handling much more than others..
That's what I'd like to see them sorting out as a matter of urgency. Of course that's hardly an unbiased opinion.....

[HD Boy]

1 out of 5. I would like to know which one is correct.

[General Maximus]

I would like to know which one is correct.

50mbit. It is going to be another 2 years before they get round to doing 200mbit here I would think.

Yes and yes respectively! :)

sweet, that means i'll never be stm'd because my area has got extremely low utilisation which makes me wonder why we are never one of the first areas to be upgraded. They do the trials here so if it works perfectly you would have thought they would just make the change permanent instead of putting it back to how it was only to upgrade it/us again

[HD Boy]

It is going to be another 2 years before they get round to doing 200mbit here I would think.
Really ?

As far as the rest goes 100Mb is not getting upgraded to 200Mb any time soon so no worries there. 200Mb as a new tier around Olympics time. http://www.cableforum.co.uk/board/35339801-post40.html

[General Maximus]

Really ?]

Ja, they started flapping about 100mbit just as I got upgraded to 50mbit two years ago and I have only just got it which is why i want a vmng300 because i know I am not going to need a shub any time soon (sorry for going off topic)

[Chrysalis]

Combination of byte count and port load, with progressively more aggressive penalties as high usage continues. In other words once degraded if you keep caning it for all it's worth you experience further degredation ;)

Will it be considered reasonable if the script has to throttle 24/7 and a large % of users to keep the load down?

[Synthetic]

Just rebooted the superhub and we seem to have received this!


Primary Downstream Service Flow
Downstream(0)
SFID 598
Max Traffic Rate 110000000 bps
Max Traffic Burst 10000 bytes
Mix Traffic Rate 0 bps

https://www.cableforum.co.uk/images/local/2011/12/42.png

[General Maximus]

it's fluff

[qasdfdsaq]

I could tell you but then I'd have to kill you.

Tell me and kill him. Problem solved.

[qasdfdsaq]

Traffic Management v2 will deal with that.
Should I be scared?

[Synthetic]

it's fluff

I know this?

Was simply stating we have received the new config for it

[qasdfdsaq]

Yes and yes respectively! :)
If this is true (and you have got my hopes up on false pretenses in the past) this is the most sensible, fair, and logical thing VM has ever done.

---------- Post added at 18:21 ---------- Previous post was at 18:20 ----------

Ja, they started flapping about 100mbit just as I got upgraded to 50mbit two years ago and I have only just got it which is why i want a vmng300 because i know I am not going to need a shub any time soon (sorry for going off topic)
Indeed, my area doesn't even have the full 50mb service yet, 100mb will be another 6 months to a year, 200 isn't even close.

---------- Post added at 18:23 ---------- Previous post was at 18:21 ----------

I reckon some people are actually magpies who download and burn all day long, but actually they transfer their largess to the cloud because they can. They then say that they have a massively awesome collection of music and films in the cloud which they never watch or listen to. However, this is cool because wow it's awesome man. Bring on 400mb/40mb man.
I used to be like this, literally caned my 0.3/0.5/0.6/0.75/1.5/4.0/10.0 connection 24/7 to within 90% of it's maximum theoretical capacity for days or weeks on end. 75% of my total income would be spent buying more hard drives to put stuff on. But HDD sizes haven't grown as fast as broadband speeds so now I've started deleting a lot of "single-use" stuff after use :P

[Rob King]

Just rebooted the superhub and we seem to have received this!


Primary Downstream Service Flow
Downstream(0)
SFID 598
Max Traffic Rate 110000000 bps
Max Traffic Burst 10000 bytes
Mix Traffic Rate 0 bps

https://www.cableforum.co.uk/images/local/2011/12/42.png

not been updated yet

Max Traffic Rate 102400000 bps
Max Traffic Burst 10000 bytes
Mix Traffic Rate 0 bps

[qasdfdsaq]

http://www.cableforum.co.uk/board/35342302-post38.html

---------- Post added at 18:38 ---------- Previous post was at 18:38 ----------

Yay it's official.

Yep all 50Mb customers are being upgraded to 100Mb progressively.

[Andrewcrawford23]

If this is true (and you have got my hopes up on false pretenses in the past) this is the most sensible, fair, and logical thing VM has ever done.

---------- Post added at 18:21 ---------- Previous post was at 18:20 ----------


Indeed, my area doesn't even have the full 50mb service yet, 100mb will be another 6 months to a year, 200 isn't even close.

---------- Post added at 18:23 ---------- Previous post was at 18:21 ----------


I used to be like this, literally caned my 0.3/0.5/0.6/0.75/1.5/4.0/10.0 connection 24/7 to within 90% of it's maximum theoretical capacity for days or weeks on end. 75% of my total income would be spent buying more hard drives to put stuff on. But HDD sizes haven't grown as fast as broadband speeds so now I've started deleting a lot of "single-use" stuff after use :P

once 100mb upgrades are done im pretty sure wha ti have read about the upgrade it will be ready for 200mb, 400mb, 1.5gbit (well i think it doesnt require another upgrade) ie all teh trials and it bea quick upgrade as the ocnifguration is there for it once upgrade to 100mb the problem i think is all teh headend where out of date and couldnt do 100mb o had to get a big upgrade themself to do it, someoen liek inigition can probally correct me been a while since iready the stuff about 100mb upgrades

[jalzoo]

Northampton seems to have been done, Did a random speedtest and saw i was running slightly faster:

http://img818.imageshack.us/img818/9244/internetj.png
https://www.cableforum.co.uk/images/local/2011/12/41.png

[bigsinky]

belfast east upgraded now

[roughbeast]

New config here too. Needed to reboot SH to get it though. :D

https://www.cableforum.co.uk/images/local/2011/12/38.png (http://www.speedtest.net)

[Synthetic]

Seem to be rolling out the new config at a decent pace then :D

[qasdfdsaq]

once 100mb upgrades are done im pretty sure wha ti have read about the upgrade it will be ready for 200mb, 400mb, 1.5gbit (well i think it doesnt require another upgrade) ie all teh trials and it bea quick upgrade as the ocnifguration is there for it once upgrade to 100mb the problem i think is all teh headend where out of date and couldnt do 100mb o had to get a big upgrade themself to do it, someoen liek inigition can probally correct me been a while since iready the stuff about 100mb upgrades
No, once the 100mb upgrades are done it will only be ready for 100mb, further upgrades are required for proper 200mb. Even more upgrades and a new CPE are required for 400mb.

The total capacity they're putting in per area for 100mb is only 200mb. Not even close for 1.5Gb, most of their current network isn't even remotely capable of handling that.

[BenJSmyth]

New config has been applied here near Crawley too. Had to reboot the Superhub for the change to happen.

[Rob King]

not been updated yet

Max Traffic Rate 102400000 bps
Max Traffic Burst 10000 bytes
Mix Traffic Rate 0 bps

rebooted tonight

110000000 bps

but still can't get over 97 mb on a speedtest

[Ignitionnet]

I do so love giving you guys these gems, especially when they relate to upgrades of 100Mb, when I don't even have 5Mb upstream available to me yet :p:

The network will be in a position to support 200Mb services once upstream bonding is enabled. All areas on 4 downstreams will have sufficient downstreams available, subject to licencing, to go to 8 downstreams. This is enough to adequately support 200Mb so long as nodes aren't too large. The additional downstreams are supplied through a combination of new line cards and rearrangement of EQAMs.

[roughbeast]

Good to see my performance graph step up a notch or two.

The upload speed is rather variable and somewhat disappointing. It would be good to see the config changed for that too, so we can truly get 10:1.

http://www.speedtest.net/results.php?sh=5746d71c650d241a81991ae319fca2d4&ria=0

Meanwhile how about joining the speed wave!

http://www.speedtest.net/wave/e1169e1735a7c94d

[Ignitionnet]

No point from VM's angle in upgrading the upstream, they're struggling enough to supply 10.24Mb/s and it's not advertised so not subject to the same regulations.

I would join your speed wave but I'm not sure if my 53Mb downstream would help and my 1.75Mb up definitely wouldn't.

[roughbeast]

No point from VM's angle in upgrading the upstream, they're struggling enough to supply 10.24Mb/s and it's not advertised so not subject to the same regulations.

When VM rolls out 8 downstream channels should they also be increasing the upstream channels to 2? My >350Mb trial modem had 8 channels down and 2 up. Upstream was configured to 25Mb. This gave me 24Mb up.


Right now the upstream is not very consistent. As you say VM seem to be struggling to deliver. Two up channels would spread the load, would they not? Surely they would have to be capable of finding an extra channel up when they roll out 200Mb/20Mb.

I would join your speed wave but I'm not sure if my 53Mb downstream would help and my 1.75Mb up definitely wouldn't.

13 folk have joined the speed wave so far. Your connection would be one of the better ones.............. apart from your upstream. ;)

[Rob King]

i' m getting 104 mb download on speedtest but no faster than 9.4mb upload any one know if virgin media was upgrading the upload speeds too ?

[roughbeast]

i' m getting 104 mb download on speedtest but no faster than 9.4mb upload any one know if virgin media was upgrading the upload speeds too ?


Check 2 comments above this one. ;) Ignit usually knows.

http://www.cableforum.co.uk/board/35346870-post80.html

[Ignitionnet]

i' m getting 104 mb download on speedtest but no faster than 9.4mb upload any one know if virgin media was upgrading the upload speeds too ?

Yes I know, and no they aren't.

[Zee]

Speed Upgrades.

This is my guess

10MB > 20MB
30MB > 40MB
50MB > 60MB
100MB stays the same
New tier of 200MB in 2012

Its more likely

10+20 goes to 30
30 goes to 60
50 gets upgraded to 100, 100 stays the same and possibly a new service in 2012.

[Ignitionnet]

When VM rolls out 8 downstream channels should they also be increasing the upstream channels to 2? My >350Mb trial modem had 8 channels down and 2 up. Upstream was configured to 25Mb. This gave me 24Mb up.

Right now the upstream is not very consistent. As you say VM seem to be struggling to deliver. Two up channels would spread the load, would they not? Surely they would have to be capable of finding an extra channel up when they roll out 200Mb/20Mb.

There's already a second channel in most areas and a third in some, these aren't yet bonded though.

The standard configuration seems to be 45.8MHz, 35.8MHz and 27.4MHz.

[Andrewcrawford23]

No, once the 100mb upgrades are done it will only be ready for 100mb, further upgrades are required for proper 200mb. Even more upgrades and a new CPE are required for 400mb.

The total capacity they're putting in per area for 100mb is only 200mb. Not even close for 1.5Gb, most of their current network isn't even remotely capable of handling that.

the 200 and 400mb trails are being done in the same areas that have the same upgrade as what getting done and if virgin didnt future proof it then there dum because they need ot pay mroe money out, i think yoru right about 1.5gb as it ina one area trial and using a different configuration

[Chrysalis]

I do so love giving you guys these gems, especially when they relate to upgrades of 100Mb, when I don't even have 5Mb upstream available to me yet :p:

The network will be in a position to support 200Mb services once upstream bonding is enabled. All areas on 4 downstreams will have sufficient downstreams available, subject to licencing, to go to 8 downstreams. This is enough to adequately support 200Mb so long as nodes aren't too large. The additional downstreams are supplied through a combination of new line cards and rearrangement of EQAMs.

how will you know its enough, based on what?

its not based on the 100mbit data.

what happens if the node is too large.

simply put its enough as long as either noone actually signs up for 200mbit or if they do sign up they dont do any sort of sustained downloading at the same time as high utilisation periods.

Your info of whats going on is appreciated however your extra comments seem very out of touch with reality.

---------- Post added at 18:50 ---------- Previous post was at 18:46 ----------

There's already a second channel in most areas and a third in some, these aren't yet bonded though.

The standard configuration seems to be 45.8MHz, 35.8MHz and 27.4MHz.

given that upstream is already stretched in significant numbers of areas, how are you confident simply bonding existing highly utilised channels will handle 20mbit upload speeds?

its logical to assume double burst needs double capacity.

[roughbeast]

Good questions Chrysalis. Ignit's answers will be useful.

My >300Mb trial modem had two bonded channels up and 8 down. I don't understand, yet, the significance of the bonded bit.

[Chrysalis]

Unfortenatly i dont expect an answer.

Interesting info from yourself that in your trial VM were capable of bonding many months ago yet never rolled it out yet. The main significance of the bonding is that the 200mbit service will have a 20mbit upload and the upstream channels are only 18mbit in capacity. So to allow 20mbit it needs 2 or more of the channels. However my concerns relate to overall capacity of these channels as I highly suspect not too many areas have 20mbit of unutilised bandwidth available on existing channels.

[morley04]

So what will happen to the customers who cannot take advantage of the new channel bonding as the VMNG is only capable of 4 downstream and the upstream im not sure about.

[craigj2k12]

the VMNG300 can handle 4 upstreams

[morley04]

Oh right so will we have to either upgrade or will they swap the old modems ( Free ) so we can make use of the 8 Channels or will it cost us the £70 odd for the Hub

[craigj2k12]

they will give them out for free, ill probably be keeping the VMNG for lower ping times, hopefully the upstream bonding will help this further

[morley04]

And is this 100% confirmed on the free super hub or just what we would like?

[craigj2k12]

they give them out at the drop of a hat anyway, youll have no problem getting one for free

[morley04]

Really lol might see what they have to say if lets say my modem becomes sick for a few days then pulls through if the hub is rubbish

[craigj2k12]

wouldnt try it, youll never get teh modem activated again, i had to go to the CEO to get mine back :(

[morley04]

Iv'e heard of people being able to keep both MAC on there account so they were able to swap between them.

[Ignitionnet]

Good questions Chrysalis. Ignit's answers will be useful.

My >300Mb trial modem had two bonded channels up and 8 down. I don't understand, yet, the significance of the bonded bit.

Due to excess complaining and either colouring threads due to or directly turning them to the capacity problems in his own area I as a general rule don't see his posts let alone respond to them, sorry!

Significance of bonding relates to statistical contention - the more members of a certain group that need to saturate their capacity to fill a pipe the less likely it is to happen.

100 x 10Mb users on a 100Mb pipe are far less likely to have 10% of them using capacity at the same time and maxing the pipe out than 10 x 10Mb users on a 10Mb pipe.

Now the contention ratio is the same, 10:1, however you need 10 people in the group of 100 to simultaneously max their capacity versus 1 person. The first situation is unlikely, the second one inevitable.

Even without upgrades bonding improves the equation, it's harder for say 150 customer to use 36Mb of upstream capacity than it is for 75 to use 18Mb.

For more on statistical contention Google is your friend, it's a well explained phenomenon both mathematically and practically in broadband networks.

The key part about the bonding was that to preserve the 10:1 ratio between downstream and upstream VM will need to bond 2 upstream channels as their current use of 16QAM only gives 18Mb of capacity. It's not about how good or otherwise it'll be, it literally has to be done and works fine so long as the network is managed properly in terms of number of customers on each segment and appropriate traffic management.

The key components of Virgin's problems right now are the number of customers per segment (too many) and the traffic management on 100Mb specifically (none).

[craigj2k12]

i had that, the CEO office doesnt de-activate the superhub, leaving it activated but not assigned to an account, then activates the modem, when I upgraded to 100mb i lost the superhub, and when I asked for both to be put back they said it wasnt possible

[Ignitionnet]

Iv'e heard of people being able to keep both MAC on there account so they were able to swap between them.

Not standard, and not likely to happen just because a customer wants a choice of CPE. Requires manual messing around with the account and may be reset by automated systems. Modem mode Superhub works just fine.

[morley04]

Thanks for the info ill see what they say about sending me one out for free

[Chrysalis]

Due to excess complaining and either colouring threads due to or directly turning them to the capacity problems in his own area I as a general rule don't see his posts let alone respond to them, sorry!

Significance of bonding relates to statistical contention - the more members of a certain group that need to saturate their capacity to fill a pipe the less likely it is to happen.

100 x 10Mb users on a 100Mb pipe are far less likely to have 10% of them using capacity at the same time and maxing the pipe out than 10 x 10Mb users on a 10Mb pipe.

Now the contention ratio is the same, 10:1, however you need 10 people in the group of 100 to simultaneously max their capacity versus 1 person. The first situation is unlikely, the second one inevitable.

Even without upgrades bonding improves the equation, it's harder for say 150 customer to use 36Mb of upstream capacity than it is for 75 to use 18Mb.

For more on statistical contention Google is your friend, it's a well explained phenomenon both mathematically and practically in broadband networks.

The key part about the bonding was that to preserve the 10:1 ratio between downstream and upstream VM will need to bond 2 upstream channels as their current use of 16QAM only gives 18Mb of capacity. It's not about how good or otherwise it'll be, it literally has to be done and works fine so long as the network is managed properly in terms of number of customers on each segment and appropriate traffic management.

The key components of Virgin's problems right now are the number of customers per segment (too many) and the traffic management on 100Mb specifically (none).

Ignition I am not mentioning my area in recent posts, but will remain to criticise VM. It seems you have took offense to the criticism heading VMs way.

Now another question which I hope roughbeast will repeat again so you will answer it.

You have just said statistical contention is important, this I agree with.

With that in mind and that there will be 200mbit user's on a 400mbit pipe like there is 100mbit user's on a 200mbit pipe, why do you think that will work when you just said having 10mbit users on a 10mbit pipe is poor. Yes its not quite the same 1 user 100% of capacity but 1 user 50% of capaicty isnt a whole lot better.

Also in regards to the bonding the top tier end user's speed are been doubled so the statistical contention remains the same.

So the question is

Example

You say smaller node sizes is better.

Yet you also say more users on same contention ratio sharing bigger pipe is better which contradicts the above.

So why dont VM merge say 4 segments into one large segment with 32 channels and 8 upstreams instead?

Having 200mbit users with 32 channels even tho the contention ratio is the same would be much better, in addition segments filled with students could be mixed with OAP segments to balance things out.

[roughbeast]

Now that's a question I always wanted the answer to Chrysalis. I wonder if Ignition has the answer. :D

Did I do good?

-----------------------------------------------------------------------

However I think I understand Ignition's response better than your follow-up question. To me a key point is that it is inevitable that 1 out of 10 people on a 10Mb pipe will at some point use up 10% (1mb) of the capacity. It must happen all the time! To use up 10% (10Mb) of a 100Mb pipe with a 100 users in it is more difficult. It requires 10 of those 100 users to be simultaneously using 1Mb of capacity. That will probably happen quite often, but not inevitably. For the other 90 users to be using the other 90Mb simultaneously is very unlikely, much less likely than the other 9 users using the remaining 9mb of a 10Mb pipe.

You asserted that Ignition said that smaller nodes were better. I didn't catch him saying that in this context so I don't know if he is being contradictory.

Your question about merging 4 segments so more customers have more space sounds sensible. 10 users within 8x18Mb channels sounds less advantageous than 40 using 32x18Mb channels.

I bet there is an engineering obstacle to this. I can't believe it hasn't occurred to VM.

BTW the 10 or so 200Mb trialists in Coventry were on a 1Gb pipe. A 10Gb pipe was held in reserve, but was never needed.

[AndyCalling]

The key components of Virgin's problems right now are the number of customers per segment (too many) and the traffic management on 100Mb specifically (none).

This has always been my puzzle. To my mind, if you need to control the usage of the top 5% of capacity users, the declared goal of the system, then the current system of speed curbing in traffic management is weird. My reasoning is as follows:

The top 5% of capacity users are almost certainly going to be on the top tier service (currently 100meg).

To catch the top 5%, a suitable usage limit should be placed on top tier and when exceeded their speed is limited much like the current system on the lower tiers. Similar for upstream.

That should catch the top 5% of capacity users. The same limits should be placed on other tiers to prevent that top 5% from moving to 50meg services and sacrificing speed for unlimited capacity. Standard lower tier users will never get close to these limits though, as they would be designed for the 100meg service, and so the lower tiers would effecitvely have no limits to worry about.

Currently the top 5% get away scot free leaving the lower tier customers to get restricted so as to open up capacity for those top 5% to gobble up. This is the reverse of the stated purpose of the policy and such a policy is not going to be viable once Youview gets hold.

Clearly it needs addressing. Let's hope someone is actually thinking things through logically. I have no speed issues but I fear the day they will happen and am keen to see a logical policy put in place that actually targets the top 5% instead of missing them completely and restricting everyone but the top 5%.

[Daveoc64]

top 5% of capacity users

IMO this was merely an excuse to cover up for serious underinvestment in parts of the network (*cough* Telewest *cough*)

[AndyCalling]

IMO this was merely an excuse to cover up for serious underinvestment in parts of the network (*cough* Telewest *cough*)

Whether the 5% figure is accurate or not, the only reason to control usage is to relieve pressure on the network and the only sensible way to do that is to deal with the top percentage of users. Otherwise, there is no reason to have a policy at all. Until the percentage targetted is updated by VM we can only work with the info we have when assessing the success of the policy in place and the approach to reforming it.

Whatever that percentage is though, my point is still valid.

[Chrysalis]

Now that's a question I always wanted the answer to Chrysalis. I wonder if Ignition has the answer. :D

Did I do good?

-----------------------------------------------------------------------

However I think I understand Ignition's response better than your follow-up question. To me a key point is that it is inevitable that 1 out of 10 people on a 10Mb pipe will at some point use up 10% (1mb) of the capacity. It must happen all the time! To use up 10% (10Mb) of a 100Mb pipe with a 100 users in it is more difficult. It requires 10 of those 100 users to be simultaneously using 1Mb of capacity. That will probably happen quite often, but not inevitably. For the other 90 users to be using the other 90Mb simultaneously is very unlikely, much less likely than the other 9 users using the remaining 9mb of a 10Mb pipe.

You asserted that Ignition said that smaller nodes were better. I didn't catch him saying that in this context so I don't know if he is being contradictory.

Your question about merging 4 segments so more customers have more space sounds sensible. 10 users within 8x18Mb channels sounds less advantageous than 40 using 32x18Mb channels.

I bet there is an engineering obstacle to this. I can't believe it hasn't occurred to VM.

BTW the 10 or so 200Mb trialists in Coventry were on a 1Gb pipe. A 10Gb pipe was held in reserve, but was never needed.


Well he said they had too many users per segment, so by that I assume he means the node sizes need to be reduced as realistically the only way to reduce the users is either to move some to another segment, or split the node into smaller nodes. If there is a 3rd way someone is welcome to tell me.

So the way I see it if VM are to reduce node sizes in an attempt to support higher speeds then its logical to have those nodes still as one but with the extra capacity instead.

Do you agree its less probable to have 4 200mbit users active at once on a 800mbit pipe than it is 2 200mbit users on a 400mbit pipe?

[kwikbreaks]

Now that's a question I always wanted the answer to Chrysalis. I wonder if Ignition has the answer. :D

Did I do good?

No you didn't. Ignition said he has Chrysalis on his ignore list so doesn't see his posts when logged in. You need to quote or repeat the specific text you want answering and hope a) you get an answer and b) that the answer is correct.

---------- Post added at 08:43 ---------- Previous post was at 08:34 ----------

... the only way to reduce the users is either to move some to another segment, or split the node into smaller nodes. If there is a 3rd way someone is welcome to tell me.They can continue as they are and just let everything go to rats so folks leave. That will eventually balance out as a service that meets the needs of the (remaining) customers.

I suspect that they will be putting their faith in Traffic Management Mk II though as trailed by the man with inside info. If that does indeed sort out the highly overutilised areas it will seriously miff the users causing the problem and they may well end up moving on giving the effect of the old "detrimental use" letters but still allowing the holy grail of VM marketing - "unlimited" to be used in their adverts.

[roughbeast]

Well he said they had too many users per segment, so by that I assume he means the node sizes need to be reduced as realistically the only way to reduce the users is either to move some to another segment, or split the node into smaller nodes. If there is a 3rd way someone is welcome to tell me.

So the way I see it if VM are to reduce node sizes in an attempt to support higher speeds then its logical to have those nodes still as one but with the extra capacity instead.

Do you agree its less probable to have 4 200mbit users active at once on a 800mbit pipe than it is 2 200mbit users on a 400mbit pipe?

Yes all of us agree with that I think. 4 people are less likely to be using the system all at once than 2 people, whatever the size of the pipe. Someone is more likely brewing a cup of tea or taking a dump. It makes sense, for statistical reasons, to put more people in bigger pipes than spreading them over a number of smaller pipes.

You feel that Ignitions logic regarding size of nodes is to have smaller ones to increase capacity, which appears to be contradictory to the above logic.

Well I am sure Ignition can square that logic somehow by pointing out some misconception you may have.

Meanwhile, I do not understand why, if on the Coventry trial we had a 10Gb pipe in reserve, more capacity cannot be put in from the centre. Here I reveal the fact that I need to do some reading. I do know that Coventry was chosen for the trials because it had spare slots at street level. Is that the point then? It is the limited capacity at street level that is the problem and that architectural decisions made historically have limited that capacity, though in some locations more than others. You can only do so much by upgrading kit, such as network cards.

A dullard like me would just say, "Lay some more fibre down then!" I guess that is too expensive.

Perhaps someone could point me in the direction of some really good descriptions of how the network works, so I do not continue stumbling into these conversations knowing less than half the theory! :dunce:

Edit.............................The above was written whilst Kwikbreaks was responding

[kwikbreaks]

I can't make any informed comment on whether or not larger than 400Mbps pipes are economically possible across the network - I suspect not as it's obvious that the low capacity local pipes are what cause issues when high speed connections get used in anything but short bursts so if it was possible without splashing the cash (or in VMs case extending the already astronomical overdraft) it would have been done.

I can comment on ...
4 people are less likely to be using the system all at once than 2 people, whatever the size of the pipe. Someone is more likely brewing a cup of tea or taking a dump.
I can quite easily fully utilise my connection while doing either of those things. I'd also suggest that those taking the higher speed connections are far more likely to be doing so than 10Mbps customers whose connections quite possibly do consume nothing while they take a leak etc.

[Chrysalis]

I suspect that they will be putting their faith in Traffic Management Mk II though as trailed by the man with inside info. If that does indeed sort out the highly overutilised areas it will seriously miff the users causing the problem and they may well end up moving on giving the effect of the old "detrimental use" letters but still allowing the holy grail of VM marketing - "unlimited" to be used in their adverts.

I agree, I think they banking on that 90% at least as its the cheapest thing to do.

Interesting thoughts on it been used to purposely severely throttle to the point to make the users "want" to leave, it will be interesting to see if VM deliberatly throttle heavily for that purpose. Will we start seeing 0.1mbit speedtests from users who have downloaded a few TB?

---------- Post added at 09:35 ---------- Previous post was at 09:31 ----------



Meanwhile, I do not understand why, if on the Coventry trial we had a 10Gb pipe in reserve, more capacity cannot be put in from the centre. Here I reveal the fact that I need to do some reading. I do know that Coventry was chosen for the trials because it had spare slots at street level. Is that the point then? It is the limited capacity at street level that is the problem and that architectural decisions made historically have limited that capacity, though in some locations more than others. You can only do so much by upgrading kit, such as network cards.

Edit.............................The above was written whilst Kwikbreaks was responding

I agree with kwikbreaks on this in that the reason it probably hasnt been done is I expect its more expensive than traffic management and possible node splits, as the superhubs for a start are only capable of 8 downstream channels, so new modems would need to be issued for 16. So the truth is most likely cost. So instead of abandoning the idea VM just going ahead anyway and probably hoping the new traffic management does enough and that hardly anyone signs up and uses it. As the primary gain of 200mbit is marketing boasting rights, they probably will still make more profit of lower tier lower usage customers. Also bear in mind with the fluff the config will probably be 220mbit not 200mbit.

[Ignitionnet]

Yes all of us agree with that I think. 4 people are less likely to be using the system all at once than 2 people, whatever the size of the pipe. Someone is more likely brewing a cup of tea or taking a dump. It makes sense, for statistical reasons, to put more people in bigger pipes than spreading them over a number of smaller pipes.

You feel that Ignitions logic regarding size of nodes is to have smaller ones to increase capacity, which appears to be contradictory to the above logic.

Well I am sure Ignition can square that logic somehow by pointing out some misconception you may have.

Yes, reducing node size doesn't reduce the total bandwidth available it reduces the amount of modems sharing it and increases capacity per modem.

Splitting a 1000 home node (more accurately called a service group) with 400 active customers on it, for the sake of argument all on the DOCSIS 3 network served by 4 downstreams and 2 upstreams, 200Mb down and 2 x 18Mb up into 2 x 500 home nodes both of which will also have 4 downstreams and 2 upstreams doubles available bandwidth per home passed and improves statistical contention as the cohort size is smaller, from 400 to 200 modems.

Yes it still takes only 2 x 100Mb users using their full capacity simultaneously to saturate either node, but if there were say 8 100Mb customers on the 1000 home node and there's only 4 on each of the 500 home nodes the maths looks much healthier.

---------- Post added at 13:59 ---------- Previous post was at 13:55 ----------

Meanwhile, I do not understand why, if on the Coventry trial we had a 10Gb pipe in reserve, more capacity cannot be put in from the centre. Here I reveal the fact that I need to do some reading. I do know that Coventry was chosen for the trials because it had spare slots at street level.

There was some spare room on the RF network at Coventry for the extra 8 downstreams and 2 upstreams you guys were provided.

The 10Gbps was to ensure that you guys wouldn't run out of core bandwidth.

The issue is, and remains, the DOCSIS downstreams and upstreams that serve the areas, 10Gbps or 1Gbps is irrelevant if there's only 800Mbps hitting the uBR, and having the extra room out of the back of the uBR is pointless for congestion relief if an area's DOCSIS network is overloaded.

The bottleneck is usually that last few hundred metres, not the core network, so anything past that bottleneck doesn't help. You still connect to the uBR at 200Mbps-400Mbps shared between your node / service group however many 10Gbps backhauls come out of the back of it.

[finaldest]

Hi all
New to the forum and have been following this discussion so thought I would register.

A question for Ignitionnet regarding
quote "The bottleneck is usually that last few hundred metres"

If this is indeed the case would it not be in VM best intrest to upgrade the cable run from the cabinet to FTTH? If this is possible in order to remove the bottleneck.

[greeninferno]

why can't Virginmedia specifically target those using torrents and just those users?

[kwikbreaks]

why can't Virginmedia specifically target those using torrents and just those users?They say that they do but the number of areas with severe upstream contention says it must be very easy to evade the shaping.

Plus you can screw it all up with nntp which they don't effectively shape or even http downloads from file hosting sites.

Apparently TM Mk2 will be more load and byte count based so all those who CBA to use a PVR will be moaning too then.

[Chrysalis]

why can't Virginmedia specifically target those using torrents and just those users?

its not a good way to go about it to be honest.

its ok to target heaviest users but I dont agree with targeting protocols.

Also VM have already tried to target torrents and its evident its not an efficient way of traffic management.

1 - light torrent users get penalised which when they are light users isnt really a fair way to deal with it.
2 - there is false positives which seems to mainly affect gamers.
3 - it can be easily evaded which defeats the purpose of it in the first place.

The new system which is due early next year which will not target torrents but will get a lot of torrent users anyway as it will target heavier users. It will not be evadable other than to stop downloading/uploading.

How effective will be remains to be seen, I expect in some areas it will need to be draconian to be effective.

[roughbeast]

Thanks for all the info and analysis guys. I am gradually getting to grips with it.

I found this useful presentation from way back. Hopefully other novices will find it useful too. (You will need to run it in IE though.)

http://homepage.ntlworld.com/draig.goch/

[Andrewcrawford23]

it is a little out of date but mostly right or it works fien in other browsers nto jsut ie

---------- Post added at 09:58 ---------- Previous post was at 09:56 ----------

its not a good way to go about it to be honest.

its ok to target heaviest users but I dont agree with targeting protocols.

Also VM have already tried to target torrents and its evident its not an efficient way of traffic management.

1 - light torrent users get penalised which when they are light users isnt really a fair way to deal with it.
2 - there is false positives which seems to mainly affect gamers.
3 - it can be easily evaded which defeats the purpose of it in the first place.

The new system which is due early next year which will not target torrents but will get a lot of torrent users anyway as it will target heavier users. It will not be evadable other than to stop downloading/uploading.

How effective will be remains to be seen, I expect in some areas it will need to be draconian to be effective.

what method are you talkign about coming out next year as all known methods for targetting heavy users to my knowledge can be evaded so just wondering which method you mean so i know if it is one (no i aint aheavy user but i do download more than the limits on stm currently so it could affect me so ill need to know if i should change the way i download like i did for stm)

[Chrysalis]

If you evade a throttle that targets heavy users than its not a throttle that targets heavy users.

eg. you cant evade STM, if you get STM'd you stuck with it until it wears off

Alot of isps target protocols like p2p then call it "targeting heavy users" when its nothing of the sort, its targeting protocols.

[Andrewcrawford23]

If you evade a throttle that targets heavy users than its not a throttle that targets heavy users.

eg. you cant evade STM, if you get STM'd you stuck with it until it wears off

Alot of isps target protocols like p2p then call it "targeting heavy users" when its nothing of the sort, its targeting protocols.

evading by not going over the stm limits isnt evading in the form that means you dnt get stm even though downloading at full rate im just sticking to vm rules but you never answer my question what method :p

[kwikbreaks]

...but you never answer my question what methodIgnition has said it will be a straightforward protocol agnostic byte count but moderated by local network loading. That will catch everything including using VPNs and the like. If it works it will cause moaning for sure.

[Chrysalis]

Yes it will be like the proposal I posted here last year which turns out to be what comcast use and what VM will be using soon.

[Andrewcrawford23]

yeah that cant be evaded it more a less protcol stm without targeting a protocol which is the best way to do it, and it should stop the heavy users and torrent seeders but that is dependent on the rules they apply, i cant remember the system just now beena while sinc ei seen it

but take for a example virgin stm if you download more than 7gb you are throttle now if that limit is to small and a non heavy user say streaming hd video that is 9gb will trigger it and be unfairly throttled but someone who is downloading and uplading constanly knowing the rule might say oh i download 7gb in 5 hours ok i will make sure i download 1.2gb each hour and only upload 200mb and when that time is up ill turn right back to full so that is effectily evading and not working as th heavy user isnt throttle but the light user is so in thoery the rules apply have to be made sure the limits are right from data consumed to the throttle limits i think with the current stm it should be gradly throttling ie over 10gb throttled to 75% over 18gb to 50% over 23gb throttled to 25% all the way down to 5% and the stm keep trigging the time frame to increase

[telfordcable]

Mine had been upgraded:

https://www.cableforum.co.uk/images/local/2012/01/102.png (http://www.speedtest.net)

Nice one VM

[Hugh]

Polite request - play nicely, please

[telfordcable]

File size transferred : 500.0 MB (524288000 bytes)
Total time taken : 40.78 seconds (40778 milliseconds)
Throughput : 12857.0 KB/sec [Kilobyte-per-second]
= 12.86 MB/sec [Megabyte-per-second]
= 102856.0 Kbps [Kilobit-per-second]
= 102.86 Mbps [Megabit-per-second]

[craigj2k12]

Polite request - play nicely, please

:LOL:

[qasdfdsaq]

Also in regards to the bonding the top tier end user's speed are been doubled so the statistical contention remains the same.

Not quite. Usage often does not go up linearly with max speed - double a user's speed and they may download more but not 100% more.

---------- Post added at 13:02 ---------- Previous post was at 12:59 ----------

It is the limited capacity at street level that is the problem and that architectural decisions made historically have limited that capacity, though in some locations more than others. You can only do so much by upgrading kit, such as network cards.

Yes, it's already been said but I'll reiterate - core bandwidth is not the problem, VM has plenty of it; at street level, the theoretical max a coax cable can carry, under perfect conditions and assuming no analogue, digital or OD TV would be slightly less than ~6gbps IIRC. Which isn't bad, but most of it cannot be used most of the time.

---------- Post added at 13:04 ---------- Previous post was at 13:02 ----------

If this is indeed the case would it not be in VM best intrest to upgrade the cable run from the cabinet to FTTH? If this is possible in order to remove the bottleneck.
Ideally, everyone would run FTTH but it is far too expensive, and not really a practical upgrade path right now over the current DOCSIS cable architecture.

Though to be fair, the cable from the cabinet isn't a big problem either as it can carry several gigabits, it's the number of homes and cabinets sharing one bigger cable to the fibre/optical node/CMTS.

---------- Post added at 13:05 ---------- Previous post was at 13:04 ----------

Ignition has said it will be a straightforward protocol agnostic byte count but moderated by local network loading. That will catch everything including using VPNs and the like. If it works it will cause moaning for sure.
I'd moan, as I currently evade all throttles and shaping, but as I said earlier it'd be the most logical, sensible, and fair thing VM has ever done in terms of traffic management. And about as close to the ideal/perfect solution I can think of.

---------- Post added at 13:06 ---------- Previous post was at 13:05 ----------

the 200 and 400mb trails are being done in the same areas that have the same upgrade as what getting done and if virgin didnt future proof it then there dum because they need ot pay mroe money out, i think yoru right about 1.5gb as it ina one area trial and using a different configuration
Those areas have further upgrades in excess of the 100mb upgrades to enable the trials.

The initial 100mb rollout only included 4 downstream channels and 1 unbonded upstream. That is neither capable of 200 or 400mb service.

---------- Post added at 13:07 ---------- Previous post was at 13:06 ----------

For more on statistical contention Google is your friend, it's a well explained phenomenon both mathematically and practically in broadband networks.
Ah yes, the beauty of statistical contention. Not just on broadband networks either; pretty much all shared networks involve it to some extent.

[Chrysalis]

qasdfdsaq usage goes up with max speed, the problem is isp's have a nack of underestimating it on a regular basis. However I am not reffering here to total monthly usage but rather burst speed demands on the network. A 200mbit user can and will do in most cases double the burst rate demand on the network.

So a 200mbit user downloading the same as a 100mbit user will still double the load on the port whilst downloading.

[Sephiroth]

........Ideally, everyone would run FTTH but it is far too expensive, and not really a practical upgrade path right now over the current DOCSIS cable architecture.

Though to be fair, the cable from the cabinet isn't a big problem either as it can carry several gigabits, it's the number of homes and cabinets sharing one bigger cable to the fibre/optical node/CMTS.......

Fibre or coax. It's all the same in capacity terms. The limiting factor is the number of downstream channels deployed (which is theoretically limited by the number of 8 MHz slots that divid into the downstream spectrum).

As you know, this capacity is squeezed by contention which is a function of two things: (1) the number of downstream channels deployed to an optical node; (2) the sharing strategy of VM in alloting downstream channels to locality cabinets.

There are barely 100 downstream channels available in the full downstream spectrum. A large chunk of this spectrum is currently used for TV which squeezes down further the broadband available sepctrum. I'm not sure what that is - maybe 300 MHz so about 40 DS channels available to a local hub (e.g. RDNG, HAYE). Igni knows this stuff better than I do but you see where I'm heading.

The only way of making serious inroads into top end speeds is to mimprove the infrastructure quality so that it can run at a higher QAM rating. IMO that is almost a survival matter for VM.

[Ignitionnet]

The only way of making serious inroads into top end speeds is to mimprove the infrastructure quality so that it can run at a higher QAM rating. IMO that is almost a survival matter for VM.

Not so much, past 256QAM you get into increasingly diminishing returns.

256QAM -> 1024QAM = 25% increase

The SNR including coding gain to make this happen is 37dB - 6dB above that for 256QAM.

2048QAM = 10% increase over 1024QAM but increases SNR requirement by 3dB - now up to 40dB.

4096QAM = 9% increase over 2048QAM and you're now in need of 43dB SNR.

So in return for an increase from 50Mb/s per channel to 75Mb/s per channel you've increased downstream SNR requirements by 12dB.

Increasing the number of downstream channels is, on the whole, a better way to go. VM can get RF bandwidth back by shifting TV channels from 64QAM to 256QAM and using the freed up multiplexes for additional downstreams.

My own area has tons of room free now having a 1GHz network, even 750MHz networks have 300MHz+ free thanks to analogue switch off - each analogue channel consumed 8MHz, enough for 4 HD channels.

[craigj2k12]

50mbit will be a free upgrade to 100mbit

[Ignitionnet]

Fibre or coax. It's all the same in capacity terms.

Not so much, an HFC network is limited by the capacity of the RF amplifiers in the field and the fibre optic nodes, an FTTP network has a far, far greater RF bandwidth. With an HFC you're talking hundreds of MHz, with FTTP 10s of GHz.

10Gb PON is available with 2.5Gb upstream and can even be run alongside standard 2.4Gb down, 1.2Gb up PON for legacy CPE that don't do 10G-PON.

EDIT: Just to add to the cheek a 10G-PON network not only could run alongside a GPON network, an operator could also put a full spectrum of RFOG QAM multiplexes down the piece of string for TV if they had legacy CATV CPE, an entire HFC network of RF running alongside a 10Gb/2.5Gb and a 2.4Gb/1.2Gb broadband IP link to each node.

[Chrysalis]

My own area has tons of room free now having a 1GHz network, even 750MHz networks have 300MHz+ free thanks to analogue switch off - each analogue channel consumed 8MHz, enough for 4 HD channels.

are most ares 750 or 1ghz?

[Sephiroth]

Not so much, past 256QAM you get into increasingly diminishing returns.

256QAM -> 1024QAM = 25% increase

The SNR including coding gain to make this happen is 37dB - 6dB above that for 256QAM.

2048QAM = 10% increase over 1024QAM but increases SNR requirement by 3dB - now up to 40dB.

4096QAM = 9% increase over 2048QAM and you're now in need of 43dB SNR.

So in return for an increase from 50Mb/s per channel to 75Mb/s per channel you've increased downstream SNR requirements by 12dB.

Increasing the number of downstream channels is, on the whole, a better way to go. VM can get RF bandwidth back by shifting TV channels from 64QAM to 256QAM and using the freed up multiplexes for additional downstreams.

My own area has tons of room free now having a 1GHz network, even 750MHz networks have 300MHz+ free thanks to analogue switch off - each analogue channel consumed 8MHz, enough for 4 HD channels.

That's why I said that it requires VM's infrastructure to be improved so as to support the QAM increase.

[Ignitionnet]

Little point in a QAM increase. With the advent of DOCSIS 3 more economical to just use additional channels.

[Chrysalis]

I agree with seph, whilst it may be more economical to use more channels, but its clear VM dont want to use more channels, for whatever reasons they see fit. You have told us there is free space for extra channels with the analogue turn off so the question is where are these channels?

I think you previously answered for downstream there is a licensing issue so cannot use 8 channels yet but many areas dont even have 5 channels yet and also many areas only have 2 upstream channels instead of 3 or 4 or 5 or whatever is needed to prevent congestion.

[Sephiroth]

At least Igni is consistent by saying SNR is a stumbling block. (See here (http://www.cableforum.co.uk/board/35098668-post4.html)).

But as I see it, if 1024QAM requires 38-41 dB SNR and if most of the SH's are reporting this downstream SNR value, it may be worth trialling this because modems will also acquire at 256QAM.

[Ignitionnet]

At least Igni is consistent by saying SNR is a stumbling block. (See here (http://www.cableforum.co.uk/board/35098668-post4.html)).

But as I see it, if 1024QAM requires 38-41 dB SNR and if most of the SH's are reporting this downstream SNR value, it may be worth trialling this because modems will also acquire at 256QAM.

No they won't, any modems that can't handle 1024QAM will error and/or fall offline, there is no spectrum management and no ability to downrate downstreams to accommodate modems with marginal SNRs.

VM could work around this by periodically probing modems for their downstream SNR however where do you draw the line as far as the amount of customers you allow to have a marginal or non-existent service and think of the OSS expense?

Compare this to investing in higher density line cards when you are going to be swapping some line cards out due to upstream bonding requirements anyway - no brainer.

The acid test for this really is a simple one - how many operators are running 1024QAM, and how many have supplied additional capacity simply by using 8 x 256QAM downstream compatible CPE and filling the downstream channels?

Is there a pressing need for more than 400Mbps to a single service group right now? When there is a need for more than this 16 downstream silicon both on line cards and modems is waiting.

[buckleb]

Mine had been upgraded:

https://www.cableforum.co.uk/images/local/2012/01/102.png (http://www.speedtest.net)

Nice one VM

That's a wicked ping you have there!

I had to wait until Santa brought me my new TP-Link Router before I could test out my upgrade, seems to be working just fine using Superhub in modem mode.

https://www.cableforum.co.uk/images/local/2012/01/103.png (http://www.speedtest.net)

The superhub is using 4 downstream channels and 1 upstream channel, but my area does seem to be (thankfully) free of torrent freaks.

[kwikbreaks]

Don't be jealous - I've improved yours for you...

[Hugh]

Ahem....

Polite request - play nicely, please

[Ignitionnet]

That's a wicked ping you have there!


The speed tester's ping reporting is unreliable, ignore it. On the gaming machine I have the ping time is 5ms, on this laptop it's 40ms+, both have the same latency on traceroutes.

Pinging gonzales.namesco.net [85.233.160.167] with 32 bytes of data:
Reply from 85.233.160.167: bytes=32 time=28ms TTL=52
Reply from 85.233.160.167: bytes=32 time=16ms TTL=52
Reply from 85.233.160.167: bytes=32 time=16ms TTL=52
Reply from 85.233.160.167: bytes=32 time=16ms TTL=52

Ping statistics for 85.233.160.167:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 28ms, Average = 19ms

https://www.cableforum.co.uk/images/local/2012/01/101.png

[qasdfdsaq]

qasdfdsaq usage goes up with max speed, the problem is isp's have a nack of underestimating it on a regular basis. However I am not reffering here to total monthly usage but rather burst speed demands on the network. A 200mbit user can and will do in most cases double the burst rate demand on the network.
I disagree there. Statistical contention again, here thinking of the user's own connection. A single person is unlikely to use 200mb on their own for any significant length of time - the oft-quoted most webservers only have 100mb for example. Usage goes up but nowhere near linearly - something like 20% higher usage when speed gets doubled in the last study I saw.

So a 200mbit user downloading the same as a 100mbit user will still double the load on the port whilst downloading.
Assuming all the conditions are favourable, yes, but they would only do so for half the amount of time. Again, reducing statistical contention.

---------- Post added at 15:47 ---------- Previous post was at 15:41 ----------

are most ares 750 or 1ghz?
I believe upgrading from 750 to 1Ghz was part of the 100mb rollout upgrades.

[Ignitionnet]

I believe upgrading from 750 to 1Ghz was part of the 100mb rollout upgrades.

Nah, most areas are 750MHz or 860MHz. Overbuilding has been done on areas running at 550MHz, areas at 750MHz have only had work done where needed for upload upgrades and downstream laser changes to permit use of 256QAM in areas previously doing 64QAM.

[Chrysalis]

The speed tester's ping reporting is unreliable, ignore it. On the gaming machine I have the ping time is 5ms, on this laptop it's 40ms+, both have the same latency on traceroutes.

Pinging gonzales.namesco.net [85.233.160.167] with 32 bytes of data:
Reply from 85.233.160.167: bytes=32 time=28ms TTL=52
Reply from 85.233.160.167: bytes=32 time=16ms TTL=52
Reply from 85.233.160.167: bytes=32 time=16ms TTL=52
Reply from 85.233.160.167: bytes=32 time=16ms TTL=52

Ping statistics for 85.233.160.167:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 28ms, Average = 19ms

https://www.cableforum.co.uk/images/local/2012/01/101.png

I assumed was a tcp ping on the speedtest not a udp one which would then make it affected by tcp window sizes which are smaller on laptops which is what explanation I gave to myself why my laptop got lower ping times on it. However with your results my idea is out the window unless your laptop is tuned for large tcp window sizes or has a dodgy wireless signal.

---------- Post added at 17:56 ---------- Previous post was at 17:52 ----------

I disagree there. Statistical contention again, here thinking of the user's own connection. A single person is unlikely to use 200mb on their own for any significant length of time - the oft-quoted most webservers only have 100mb for example. Usage goes up but nowhere near linearly - something like 20% higher usage when speed gets doubled in the last study I saw.


Assuming all the conditions are favourable, yes, but they would only do so for half the amount of time. Again, reducing statistical contention.

---------- Post added at 15:47 ---------- Previous post was at 15:41 ----------


I believe upgrading from 750 to 1Ghz was part of the 100mb rollout upgrades.

They dont need to use it for a significant amount of time. Even a 200mbit user doing a 10 second speedtest can cause 10 seconds of congestion. I am talking about burst rate demand, not overall usage. Incidently its not too diffilcult to exceed 100mbit assuming no congestion on VM side, various servers now use gigabit interfaces, p2p uses multiple sources meaning they can exceed 100mbit by collective means rather than a single fast connection, giganews and the like will very unlikely still be using 100mbit interfaces, eg. every ftp file server I run is at least a gigabit interface, a few are actually multi gigabit bonded as even a gigabit is considered small now days for file hosting. The only downloads that would struggle is http downloads as they usually single stream only with web server software often not using rfc1323.

---------- Post added at 18:00 ---------- Previous post was at 17:56 ----------

Nah, most areas are 750MHz or 860MHz. Overbuilding has been done on areas running at 550MHz, areas at 750MHz have only had work done where needed for upload upgrades and downstream laser changes to permit use of 256QAM in areas previously doing 64QAM.

So those with the delayed uplift work for overbuilding are now in the best position with more useable bandwidth?

[Ignitionnet]

I assumed was a tcp ping on the speedtest not a udp one which would then make it affected by tcp window sizes which are smaller on laptops which is what explanation I gave to myself why my laptop got lower ping times on it. However with your results my idea is out the window unless your laptop is tuned for large tcp window sizes or has a dodgy wireless signal.

Why would window size affect a TCP ping?

So those with the delayed uplift work for overbuilding are now in the best position with more useable bandwidth?

Yep.

[Sephiroth]

Not in my area.

[Chrysalis]

Why would window size affect a TCP ping?



Yep.

not sure, it was just a theory.

When I used to run windows XP which had no tcp auto tuning, smaller tcp packets were noticebly slower to process with large tcp buffers configured as tcp can be tuned for one type of use but it then become suboptimal for another type of use hence the use of auto tuning in modern operating systems.

Delayed acks will slow down single small tcp packets, the most public example been WoW where gamers were disabling delayed acks in windows to halve their tcp latency in the game, large tcp windows I assumed can have an affect as well but its only a theory I havent done any testing on it.

To test my theory on windows vista or 7 one could disable auto tuning which will force a tcp buffer of 64k, this isnt huge but is bigger than what auto tuning should use for small single packets, on wireless interfaces the default buffer is much smaller than 64k. On XP one could set a high buffer size manually eg. 256k, check the ping on speedtest.net then try again with a 4k buffer size and see if it noticebly drops. If it doesnt I am wrong ;)

[qasdfdsaq]

Why would window size affect a TCP ping?

Don't think speedtest.net even uses an actual TCP ping of any kind. After all, doing so would stop it working from behind most NATs.

[Andrewcrawford23]

Don't think speedtest.net even uses an actual TCP ping of any kind. After all, doing so would stop it working from behind most NATs.

not in the way that command prompt ping command does no, but it does use tcp/udp packets

---------- Post added at 10:29 ---------- Previous post was at 10:25 ----------

Why would window size affect a TCP ping?

.

generally it wouldnt unless the user has mucked about witht he window size badly and no used something liek tcpip optimiser , basically you set the window size let says to 1024000000 instead of say 2048 (no i cant remmeber the windows size off the top of my head jsut a plain example being obviously different) then sendinga a packet not jsut tcp ping packet would be affected in time

[Ignitionnet]

The answer is it doesn't. TCP pings either use a SYN and measure time until they receive a SYN/ACK or if a session is in progress they send an invalid ACK and wait for a RST.

Window size, scaling, selective ackowledgement, etc have no impact on these.

[Ignitionnet]

not sure, it was just a theory.

When I used to run windows XP which had no tcp auto tuning, smaller tcp packets were noticebly slower to process with large tcp buffers configured as tcp can be tuned for one type of use but it then become suboptimal for another type of use hence the use of auto tuning in modern operating systems.

Delayed acks will slow down single small tcp packets, the most public example been WoW where gamers were disabling delayed acks in windows to halve their tcp latency in the game, large tcp windows I assumed can have an affect as well but its only a theory I havent done any testing on it.

To test my theory on windows vista or 7 one could disable auto tuning which will force a tcp buffer of 64k, this isnt huge but is bigger than what auto tuning should use for small single packets, on wireless interfaces the default buffer is much smaller than 64k. On XP one could set a high buffer size manually eg. 256k, check the ping on speedtest.net then try again with a 4k buffer size and see if it noticebly drops. If it doesnt I am wrong ;)

TCP window sizes don't work like that. Window sizes are a maximum and are sent to inform the remote side how much data it may have outstanding and awaiting acknowledgement. When devices send their acknowledgements is decided by their local TCP stack in conjunction with information in the initial 3 way handshake, specifically whether the bit is set in the headers indicating that SACK is acceptable and is nothing to do with window size.

You're thinking of Nagle's algorithm I suspect.

[Andrewcrawford23]

The answer is it doesn't. TCP pings either use a SYN and measure time until they receive a SYN/ACK or if a session is in progress they send an invalid ACK and wait for a RST.

Window size, scaling, selective ackowledgement, etc have no impact on these.

ive done some tests to check apart from it a pain in the back side to really change the windows size in linux and windows as they use automatic calculatiosn to adjsut window size to what ti sees as best.... but i did see a difference in ping acklodegements by about 10-20ms but its intial test i will really need to benchmark it witha a clena system and remove all other variables until then ill agree with you it probally doesnt affect

[Ignitionnet]

ive done some tests to check apart from it a pain in the back side to really change the windows size in linux and windows as they use automatic calculatiosn to adjsut window size to what ti sees as best.... but i did see a difference in ping acklodegements by about 10-20ms but its intial test i will really need to benchmark it witha a clena system and remove all other variables until then ill agree with you it probally doesnt affect

I had 10 minutes.

Here's how the latency test used by Speedtest.net works - the app requests a file called latency.txt from the server with a parameter specific to that test:

GET /speedtest/latency.txt?x=1325619351882 HTTP/1.1
Host: www.speedtest.bbmax.co.uk
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
Accept: */*
Referer: http://c.speedtest.net/flash/speedtest.swf?v=297277
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

The server responds:

HTTP/1.1 200 OK
Date: Tue, 03 Jan 2012 19:36:07 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Fri, 29 Sep 2006 15:09:15 GMT
ETag: "cc01f2-a-a17bcc0"
Accept-Ranges: bytes
Content-Length: 10
Connection: close
Content-Type: text/plain; charset=UTF-8
test=test

It does this a few times.

The app does some kind of timing between the two. Window size is a complete non-issue as the window is at no point approached and more relevantly as I said window sizes don't work like that. Nagle might be more of a factor as the app will send its request which will then sit on the TCP stack of the host machine waiting for a full MSS of data to be sent.

334 6.001751 192.168.10.12 85.233.160.167 HTTP GET /speedtest/latency.txt?x=1325619351882 HTTP/1.1
Frame 334: 489 bytes on wire (3912 bits), 489 bytes captured (3912 bits)
Arrival Time: Jan 3, 2012 19:35:51.980248000 GMT Standard Time

337 6.021832 85.233.160.167 192.168.10.12 HTTP HTTP/1.1 200 OK (text/plain)
Frame 337: 325 bytes on wire (2600 bits), 325 bytes captured (2600 bits)
Arrival Time: Jan 3, 2012 19:35:52.000329000 GMT Standard Time

[Chrysalis]

I agree nagle will be the most likely factor, the tcp window sizing on the pings was only a untested theory although on web browsing it does have an effect if too big.

[Ignitionnet]

I agree nagle will be the most likely factor, the tcp window sizing on the pings was only a untested theory although on web browsing it does have an effect if too big.

Nope that's probably Nagle and TCP delayed acks misbehaving.

Basic TCP. Window size indicates data that can be sent unacked, it doesn't indicate anything about amount of data that must be sent. In addition it gives the maximum TCP window size, this is a value that changes and starts of far smaller than the maximum due to TCP slow start.

The only loss of efficiency that an overly large window size can cause is where it's an odd multiple that doesn't fit too well with the server's transmit window and even this will cap transfer speeds at marginally below maximum, web browsing doesn't push bandwidth very hard.

EDIT:

Here's the start of a TCP transaction, note the window sizes - these are due to TCP slow start while TCP works out the link speed.

2269 77.606093 192.168.10.12 88.221.88.80 TCP 49402 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2 SACK_PERM=1
2301 77.640534 88.221.88.80 192.168.10.12 TCP http > 49402 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=5
2302 77.640569 192.168.10.12 88.221.88.80 TCP 49402 > http [ACK] Seq=1 Ack=1 Win=17520 Len=0
2303 77.641481 192.168.10.12 88.221.88.80 HTTP GET /0/RTMS/Image/SPRO-Seller_C2C-ZIF_AugustHeader_Active_Q311-325x100.gi.gif HTTP/1.1
2380 77.676750 88.221.88.80 192.168.10.12 TCP http > 49402 [ACK] Seq=1 Ack=372 Win=6912 Len=0

[Andrewcrawford23]

Nope that's probably Nagle and TCP delayed acks misbehaving.

Basic TCP. Window size indicates data that can be sent unacked, it doesn't indicate anything about amount of data that must be sent. In addition it gives the maximum TCP window size, this is a value that changes and starts of far smaller than the maximum due to TCP slow start.

The only loss of efficiency that an overly large window size can cause is where it's an odd multiple that doesn't fit too well with the server's transmit window and even this will cap transfer speeds at marginally below maximum, web browsing doesn't push bandwidth very hard.

web browsing generally doesnt push bandwiwdth very hard unless oyu have idiot webmaster who design there pages very large makign them have more data than require ie code ;) thought bbc article on web page growing from i think 50kb to 70kb in year one was quite interesting :0 not sure the exact figure jsut know bbc reported them growing quite a bit in a year i think it had a headline like people aint the only one utting on weight

[Ignitionnet]

web browsing generally doesnt push bandwiwdth very hard unless oyu have idiot webmaster who design there pages very large makign them have more data than require ie code ;) thought bbc article on web page growing from i think 50kb to 70kb in year one was quite interesting :0 not sure the exact figure jsut know bbc reported them growing quite a bit in a year i think it had a headline like people aint the only one utting on weight

Inefficiently coded web pages have interdependencies that stop them being loaded quickly as many segments have to be loaded consecutively rather than in parallel, it's not about the amount of data on the page.

[Chrysalis]

Nope that's probably Nagle and TCP delayed acks misbehaving.

Basic TCP. Window size indicates data that can be sent unacked, it doesn't indicate anything about amount of data that must be sent. In addition it gives the maximum TCP window size, this is a value that changes and starts of far smaller than the maximum due to TCP slow start.

The only loss of efficiency that an overly large window size can cause is where it's an odd multiple that doesn't fit too well with the server's transmit window and even this will cap transfer speeds at marginally below maximum, web browsing doesn't push bandwidth very hard.

EDIT:

Here's the start of a TCP transaction, note the window sizes - these are due to TCP slow start while TCP works out the link speed.

2269 77.606093 192.168.10.12 88.221.88.80 TCP 49402 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2 SACK_PERM=1
2301 77.640534 88.221.88.80 192.168.10.12 TCP http > 49402 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=5
2302 77.640569 192.168.10.12 88.221.88.80 TCP 49402 > http [ACK] Seq=1 Ack=1 Win=17520 Len=0
2303 77.641481 192.168.10.12 88.221.88.80 HTTP GET /0/RTMS/Image/SPRO-Seller_C2C-ZIF_AugustHeader_Active_Q311-325x100.gi.gif HTTP/1.1
2380 77.676750 88.221.88.80 192.168.10.12 TCP http > 49402 [ACK] Seq=1 Ack=372 Win=6912 Len=0

This I have experimented, both on servers and my desktop.

On servers if I eg. set the tcp window to 2meg, assuming there be no downsides other than faster resource saturation, I soon discovered it absolutely murdered throughput in specific scenarios, not 100% of the time but a significant amount of the time.

On a XP desktop if I set the tcp window to 256k then downloading files was faster it even helped slower adsl never mind a faster VM connection, however web browsing was most defenitly slower, loading little smilies on sites like this and text pages was slower.

Whether this is down to bad/buggy implementation on the OS's in question or by design I dont know but I tested the results numerous times.

Interesting as well is delayed acks works superior on linux over bsd and windows, but linux are not adhering to RFC guidelines, they disable nagle when the data been transferred is small so it doesnt hinder stuff it likely wont benefit.

One downside with large windows is if there is congestion/loss, a retransmit is more expensive.

With auto tuning however its ok to set max window sizes very large (multiple meg) as it always scales up from a small size.

[Ignitionnet]

You'll forgive me if I don't take too authoritatively this experimentation given you may not be aware of the various parameters that could affect his tests. Case in point:

One downside with large windows is if there is congestion/loss, a retransmit is more expensive.

Wrong on multiple levels. Firstly windows start small and increase if transmission is smooth and quick - the whole point of TCP windows is that they are congestion control and respond to congestion / loss conditions. They must increase to higher levels in order to allow maximum throughput on high BDP links (Google it). This is a common feature of all TCP stacks, the only differences as far as windows go being how aggressively they increase window size post-loss and how they manage retransmission / duplicate acknowledgement.

Secondly a retransmit is not more expensive due to window sizes, it's more expensive due to cumulative or selective acknowledgements. When a retransmit happens window sizes will be reduced in case that retransmit was forced by congestion. Windows govern how much data can be sent before an acknowledgement must be received not how frequently data must be acknowledged and therefore how much data can be lost in one shot.

For your tests to be taken in any way seriously you need to be taking packet captures and analysing them so that you can see the sliding windows, retransmits, acknowledgement pattern, etc.

EDIT: The only negative impact of TCP windows being excessively large is in terms of buffers within kernels and routers being eaten as TCP pushes out big bursts of data to try and fill windows, although I'm sure given all the servers you run professionally you knew that. I've more than once had to have customers adjust buffer sizes on routers when devices behind them are running HSTCP to fill a long, wide pipe.