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 mark@amplex.net 419.837.5015 x 1021