Sign up with Google
Roman4604
Executive Member
- Joined
- Jun 27, 2005
- Messages
- 5,554
Been capped for the first time, and I must say its quite usable (for me at least). There is however one characteristic I'm seeing thats not so good ... the rate filters are not setup in the most optimal way (from my testing).
Almost all rate mgmt equipement uses 3 parameters to enforce bw rates ...
>target rate - speed you want to enforce (e.g. 64 Kbps)
>burst - a buffer to allow for bw burst over target rate (e.g. 128000 Kb) NB: this is NOT per sec, its a buffer
>burst excess - an additional buffer on top of burst, but this acts as a loan account - what you borrow you must pay back
My testing has shown that WBS has configured the burst excess buffer way too BIG. This is what I've observed ...
If say you download a large homepage e.g. cnn.com, for the first few secs (2-4) the page rushes down at 100-200 Kbps as the burst & burst excess buffers are filled. Then after the initial rush the bw drops to way below 64 Kbps (capped target rate). I'm assuming this is happening because you now have to pay back the bw you borrowed in the initial rush.
The net result is you can seldom load a large homepage completely the first time around, as all the seconardy connections (getting images, ad banners etc.) get so starved of bandwidth they timeout, because by then you're in heavy bw debt. Since your browser caches content, reloading the page (1 or a few times) allows you to get all the secondary content as the primary is already downloaded & cached locally.
So if any WBS techies are listening out there ... reduce your burst excess buffers down to the MINIMUM. Its far less confusing to TCP/IP stacks and will give your users a SMOOTHER experience (at no cost to you). Test it yourselves!
PS: anyone out there have similar/differing capped experiences?
Almost all rate mgmt equipement uses 3 parameters to enforce bw rates ...
>target rate - speed you want to enforce (e.g. 64 Kbps)
>burst - a buffer to allow for bw burst over target rate (e.g. 128000 Kb) NB: this is NOT per sec, its a buffer
>burst excess - an additional buffer on top of burst, but this acts as a loan account - what you borrow you must pay back
My testing has shown that WBS has configured the burst excess buffer way too BIG. This is what I've observed ...
If say you download a large homepage e.g. cnn.com, for the first few secs (2-4) the page rushes down at 100-200 Kbps as the burst & burst excess buffers are filled. Then after the initial rush the bw drops to way below 64 Kbps (capped target rate). I'm assuming this is happening because you now have to pay back the bw you borrowed in the initial rush.
The net result is you can seldom load a large homepage completely the first time around, as all the seconardy connections (getting images, ad banners etc.) get so starved of bandwidth they timeout, because by then you're in heavy bw debt. Since your browser caches content, reloading the page (1 or a few times) allows you to get all the secondary content as the primary is already downloaded & cached locally.
So if any WBS techies are listening out there ... reduce your burst excess buffers down to the MINIMUM. Its far less confusing to TCP/IP stacks and will give your users a SMOOTHER experience (at no cost to you). Test it yourselves!
PS: anyone out there have similar/differing capped experiences?