On 06/15/2015 09:08 PM, Ken Pizzini wrote: > Don't you get billed by upstream based on 95th percentile, or something > other measure of transfer rate? I think it makes sense to mirror that > mechanism, making some allowance for the fact that the statistics > smear out a fair bit (most hosts use far less than the mean most of > the time, so not just a straightforward divide-by- number-of-hosts, > but dividing by some smaller number).
A straightforward divide by number of hosts would be too small right now anyway, but there's no point in paying for transit we don't need. > Yeah, I took your (apparently not-completely-serious) guideline from > the prices page, and have my server choked down to try and actually > meet it with a low bps rate, so that worst-case a monthly integral > should not reach the specified volume. I would happily allow my peak > usage rate to run higher before throttling a server, and thus help > contribute to more complete resource utilizaton. ;-) Bleah, I'm sorry. Yes, if you're causing problems we will let you know. > I'd say as a first approximation, you could try: > > (billed-capacity/current-usage) * (billed-capacity/MB-allocated) > > [with billed-capacity and current-usage being in whatever units are > used by your upstream provider(s)] as the network-rate per MB to offer. > Fudge the number a bit to allow for future users being different than > today's users (perhaps halve it for the first iteration?), then round > off to some convenient number Unfortunately I'm not sure if extrapolating from current usage makes sense since there is probably a self selection bias. > If you wanted to get fancy (but probably not worth the effort), > you could also consider only enforcing the limit at times when the > actual aggregate bandwidth utilization is getting close to what > you're paying the upstream provider(s). Then someone getting a > large spike in usage in "off hours" shouldn't be affected at all, > but bandwidth hogs would still be prevented from triggering overage > charges upstream. Or another approach would be to allow "occasional" > spikes (subjectively defined by the admins) above the posted limit, > before slapping a server with an automated enforcement. xen has a credit based scheduler for outgoing bandwidth. I haven't extensively tested it but since it's credit based it should allow for the occasional spike. I assume there's also some kind of exponential decay for the credits or a maximum amount or something but I haven't confirmed. _______________________________________________ discuss mailing list [email protected] http://lists.prgmr.com/mailman/listinfo/discuss
