Cable Forum
Page 2 of 2 1 2
Show 100 post(s) from this thread on one page

Cable Forum (https://www.cableforum.uk/board/index.php)
-   Virgin Media Internet Service (https://www.cableforum.uk/board/forumdisplay.php?f=12)
-   -   100M : Small Download Speed Upgrade (https://www.cableforum.uk/board/showthread.php?t=33683069)

craigj2k12 19-12-2011 19:20
Re: Small Download Speed Upgrade
 
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 19-12-2011 19:21
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by morley04 (Post 35348203)
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 19-12-2011 19:27
Re: Small Download Speed Upgrade
 
Thanks for the info ill see what they say about sending me one out for free

Chrysalis 19-12-2011 20:18
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35348206)
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 19-12-2011 22:05
Re: Small Download Speed Upgrade
 
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 19-12-2011 23:21
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35348206)
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 19-12-2011 23:24
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by AndyCalling (Post 35348306)
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 19-12-2011 23:39
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Daveoc64 (Post 35348307)
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 19-12-2011 23:56
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by roughbeast (Post 35348291)
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 20-12-2011 07:43
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by roughbeast (Post 35348291)
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 ----------

Quote:
Originally Posted by Chrysalis (Post 35348315)
... 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 20-12-2011 07:51
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Chrysalis (Post 35348315)
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 20-12-2011 08:11
Re: Small Download Speed Upgrade
 
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 ...
Quote:
Originally Posted by roughbeast (Post 35348345)
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 20-12-2011 08:35
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by kwikbreaks (Post 35348342)
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 ----------

Quote:
Originally Posted by roughbeast (Post 35348345)

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 20-12-2011 12:59
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by roughbeast (Post 35348345)
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 ----------

Quote:
Originally Posted by roughbeast (Post 35348345)
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 20-12-2011 13:41
Re: Small Download Speed Upgrade
 
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 20-12-2011 14:15
Re: Small Download Speed Upgrade
 
why can't Virginmedia specifically target those using torrents and just those users?

kwikbreaks 20-12-2011 14:27
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by greeninferno (Post 35348517)
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 20-12-2011 14:59
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by greeninferno (Post 35348517)
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 20-12-2011 20:55
Re: Small Download Speed Upgrade
 
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 21-12-2011 08:58
Re: Small Download Speed Upgrade
 
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 ----------

Quote:
Originally Posted by Chrysalis (Post 35348554)
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 21-12-2011 16:44
Re: Small Download Speed Upgrade
 
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 21-12-2011 17:06
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Chrysalis (Post 35349117)
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 21-12-2011 17:17
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Andrewcrawford23 (Post 35349145)
...but you never answer my question what method
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.

Chrysalis 21-12-2011 17:19
Re: Small Download Speed Upgrade
 
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 21-12-2011 17:58
Re: Small Download Speed Upgrade
 
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 28-12-2011 06:14
Re: Small Download Speed Upgrade
 
Mine had been upgraded:

https://www.cableforum.co.uk/images/...012/01/102.png

Nice one VM

Hugh 28-12-2011 07:03
Re: Small Download Speed Upgrade
 
Polite request - play nicely, please

telfordcable 28-12-2011 07:50
Re: Small Download Speed Upgrade
 
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 28-12-2011 22:41
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Hugh (Post 35351614)
Polite request - play nicely, please
:LOL:

qasdfdsaq 31-12-2011 12:07
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Chrysalis (Post 35348249)
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 ----------

Quote:
Originally Posted by roughbeast (Post 35348345)
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 ----------

Quote:
Originally Posted by finaldest (Post 35348496)
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 ----------

Quote:
Originally Posted by kwikbreaks (Post 35349161)
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 ----------

Quote:
Originally Posted by Andrewcrawford23 (Post 35347604)
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 ----------

Quote:
Originally Posted by Ignitionnet (Post 35348206)
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 31-12-2011 13:44
Re: Small Download Speed Upgrade
 
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 31-12-2011 14:45
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by qasdfdsaq (Post 35352868)
........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 31-12-2011 15:15
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Sephiroth (Post 35352948)
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 31-12-2011 15:18
Re: Small Download Speed Upgrade
 
50mbit will be a free upgrade to 100mbit

Ignitionnet 31-12-2011 15:19
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Sephiroth (Post 35352948)
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 31-12-2011 17:28
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35352954)

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 31-12-2011 20:39
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35352954)
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 01-01-2012 12:02
Re: Small Download Speed Upgrade
 
Little point in a QAM increase. With the advent of DOCSIS 3 more economical to just use additional channels.

Chrysalis 01-01-2012 13:59
Re: Small Download Speed Upgrade
 
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 01-01-2012 21:10
Re: Small Download Speed Upgrade
 
At least Igni is consistent by saying SNR is a stumbling block. (See here).

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 01-01-2012 22:27
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Sephiroth (Post 35353445)
At least Igni is consistent by saying SNR is a stumbling block. (See here).

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 01-01-2012 22:40
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by telfordcable (Post 35351604)
Mine had been upgraded:

https://www.cableforum.co.uk/images/...012/01/102.png

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/...012/01/103.png

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

kwikbreaks 02-01-2012 09:36
Re: Small Download Speed Upgrade
 
1 Attachment(s)
Don't be jealous - I've improved yours for you...

Hugh 02-01-2012 10:23
Re: Small Download Speed Upgrade
 
Ahem....

Quote:
Originally Posted by Hugh (Post 35351614)
Polite request - play nicely, please

Ignitionnet 02-01-2012 11:51
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by buckleb (Post 35353470)
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/...012/01/101.png

qasdfdsaq 02-01-2012 14:47
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Chrysalis (Post 35352927)
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.

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

Quote:
Originally Posted by Chrysalis (Post 35353012)
are most ares 750 or 1ghz?
I believe upgrading from 750 to 1Ghz was part of the 100mb rollout upgrades.

Ignitionnet 02-01-2012 15:31
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by qasdfdsaq (Post 35353655)
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 02-01-2012 17:00
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35353611)
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/...012/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 ----------

Quote:
Originally Posted by qasdfdsaq (Post 35353655)
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 ----------

Quote:
Originally Posted by Ignitionnet (Post 35353673)
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 02-01-2012 20:10
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Chrysalis (Post 35353712)
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?

Quote:
Originally Posted by Chrysalis (Post 35353712)
So those with the delayed uplift work for overbuilding are now in the best position with more useable bandwidth?
Yep.

Sephiroth 02-01-2012 20:11
Re: Small Download Speed Upgrade
 
Not in my area.

Chrysalis 02-01-2012 20:52
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35353825)
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 03-01-2012 00:50
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35353825)
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 03-01-2012 09:29
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by qasdfdsaq (Post 35353874)
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 ----------

Quote:
Originally Posted by Ignitionnet (Post 35353825)
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 03-01-2012 10:08
Re: Small Download Speed Upgrade
 
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 03-01-2012 16:10
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Chrysalis (Post 35353834)
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 03-01-2012 17:27
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35353947)
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 03-01-2012 18:54
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Andrewcrawford23 (Post 35354125)
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 03-01-2012 19:12
Re: Small Download Speed Upgrade
 
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 03-01-2012 20:31
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Chrysalis (Post 35354187)
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 03-01-2012 20:37
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35354226)
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 03-01-2012 20:59
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Andrewcrawford23 (Post 35354228)
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 03-01-2012 22:56
Re: Small Download Speed Upgrade
 
Quote:
Originally Posted by Ignitionnet (Post 35354226)
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 04-01-2012 09:16
Re: Small Download Speed Upgrade
 
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:

Quote:
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.


All times are GMT. The time now is 14:48.
Page 2 of 2 1 2
Show 100 post(s) from this thread on one page

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
All Posts and Content are © Cable Forum