[38304] in North American Network Operators' Group
Re: 95th Percentile again!
daemon@ATHENA.MIT.EDU (Richard A. Steenbergen)
Sun Jun 3 01:04:33 2001
Date: Sun, 3 Jun 2001 01:04:00 -0400 (EDT)
From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: "Greg A. Woods" <woods@weird.com>
Cc: nanog@merit.edu
In-Reply-To: <20010603045606.77B9C100@proven.weird.com>
Message-ID: <Pine.BSF.4.21.0106030101520.29677-100000@overlord.e-gerbil.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
On Sun, 3 Jun 2001, Greg A. Woods wrote:
> [ On Saturday, June 2, 2001 at 23:17:48 (-0400), Richard A. Steenbergen wrote: ]
> > Subject: Re: 95th Percentile again (was RE: C&W Peering Problem?)
> >
> > 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.
>
> What the heck are you talking about? Only a totally amateur design
> would fail to account for the possibility of a dropped sample (or any
> other of several critical issues faced by anyone using counters to
> determine the average or Nth percentile rates).
>
> In fact the accounting for bulk throughput per period is done in
> almost exactly the same as any rate-based accounting too (only the
> counter sample time might differ, but of course you can't stretch it
> too far for the former case lest you risk an undetectable wrap-around
> event).
Actually I was refering to the more common methods of rate based
measurement, MRTG. The names of the providers who use this will be
omitted. :P
--
Richard A Steenbergen <ras@e-gerbil.net> 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)
