[38329] in North American Network Operators' Group
Re: 95th Percentile again (was RE: C&W Peering Problem?)
daemon@ATHENA.MIT.EDU (Richard A. Steenbergen)
Sun Jun 3 15:40:27 2001
Date: Sun, 3 Jun 2001 15:39:53 -0400 (EDT)
From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: Alex Rubenstein <alex@nac.net>
Cc: nanog@merit.edu
Message-ID: <Pine.BSF.4.21.0106031527490.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, Jun 03, 2001 at 01:41:08PM -0400, Alex Rubenstein wrote:
>
>
>
> > No its not obvious. The SNMP byte counters are odometers - as long as
> > you get two clean samples per counter wrap you can accurately count
> > bytes. The trick is to ensure that you get a minimum of two clean
> > samples of the odometer reading per counter wrap - for high speed
> > interfaces that typically implies reading the MIB2 64 bit interface
> > counters, or triggering an SNMP poll at relatively tight time
> > intervals.
>
> 2^64 is 1.844 * 10^19
>
> at 2.5 gb/s (OC48 line speed) (2,500,000,000 bits/sec), you transfer
> 312,500,000 bytes/sec, or 298 megabytes/sec.
>
> 2^64 / 312,500,000 = 6.189 * 10^16 seconds per rollover.
>
> or, 1.719 * 10^13 hours
> or, 1,962,741,057 years.
>
> My point: at least for the near future, 64 bit counters won't roll.
Or thought about another way:
2^64 = 18446744073709551616 bytes/sec = 147573952589676412928 bits/sec.
Which means a 64 bit counter will roll over in 5 minutes at
491913175298921376 bits/sec, or 491Pbps (Petabits/sec).
Under the current naming scheme, this will be OC-9444732864. Better start
planning for 128 bit counters, we wouldn't want to be stuck in something
which doesn't scale. :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)
