On 12/6/13 8:14 PM, Michael Thomas wrote:
Thanks for the stats, real life is always refreshing :)
It seems to me -- all things being equal -- that the real question is
whether Mr. Hog is impacting your
other users. If he's not, then what difference does it make if he
consumes the bits, or if the bits over
the air are not consumed at all? Is it because of transit costs? That
seems unlikely because Mr. Hog's
800gb is dwarfed by your 3658*36gb (almost three orders of magnitude).
If he is impacting other users, doesn't this devolve into a shaping
problem which is there regardless
of whether it's him or 4 people at 200GB?
Mike
Thank you for the response!
Mr. Hog impacts other customers in that he blows the over subscription
model for that particular tower site (and specifically the sector) well
out of the norm. This specific sector has a capacity of ~10.5Mbps
download so his continuous 3.5Mbps is noticed by other customers. It's
a last mile capacity issue, not a transit cost. Heck - transit is cheap
these days and we have more than 50% spare transit capacity. Last mile
is expensive.
Most sites have sector capacities of 35 or 70Mbps (and Mr. Hogs will be
updated fairly soon).
What I'm really trying to figure out is how to offer higher speed
packages (15Mbps or higher) without having a 24x7 user kill the
over-subscription ratio or forcing a early upgrade to the tower site.
I understand the argument that you should have full capacity available
for the peak hour - but that peak hour doesn't really exist anymore with
home users. The only real usage dropoff is from 12:30am to about 7am.
Do the top 10% cause any problems? Not currently since we kept the
available speeds low.
What I am trying to figure out is how to offer higher speeds for the
average user without having to resort to lots of weaseling in the
marketing / AUP, etc. Putting some sane limits on the upper few
percent seems to make the most sense. I'm not set on billing for
overages. A rate limit at the cutoff would also be workable.
I'm not willing to do the hidden cap / fire the top user method.
Mark
--
Mark Radabaugh
Amplex
m...@amplex.net 419.837.5015 x 1021
