|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: 95th Percentile again (was RE: C&W Peering Problem?)
On Sat, 2 Jun 2001, Joe Abley wrote: > No. If you are missing a "five-minute average throughput measurement" > for some reason, you just have fewer samples to sort at the end of the > month. Chances are you still have a reasonable approximation of the > 95%ile sample value, if you don't miss too many. > > [...] > > If you have bytes-in/bytes-out counters to poll, then you're totally > right. [you also have to deal with counters being reset to zero due to > mysteriously exploding router issues]. > > [...] > > There are cases where there are no such counters, however, such as > customers who obtain transit through a shared ethernet/FDDI/ATM > interface, and where equivalent counters are not available at layer-2 > (e.g. someone else runs the switches, switches suck, etc). There are only two ways you can poll the rate, either you poll a "rate" value maintained on the device, or you poll a difference in bytes divide by the length of time between samples to calculate a rate. Either way, if the device does not support polling of the "interface" in question you are pretty screwed. No matter how you stack it, if you miss a rate sample there is no way to go back and get the data again. You either discard it and lose the ability to bill the customer for it (which demands high availability polling systems), or you make up a number and hope the customer doesn't notice. Volume polling does not suffer from this problem. Volume polling does have more difficulty detecting corruption of the counters (due to a mysteriously exploding router, etc), for example adding a GB that wasn't actually transfered while a corrupted rate sample would be discarded in the 95th percentile. There are plenty of ways to detect this kind of thing though, and you could always just discard the top X% of volume samples just in case. On a side note, there is something neat to be said for the potential of "push billing" on a Juniper, by running a local program which collects billing information and never risks being unable to reach the device, then pushes the data out when it is convenient to do so. This could also be used to get more accurate samples and reduce the load of polling. -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
|