Re: [nsp] dCEF repair pressure group (was: Re: performance impact on rate-limit)

From: Travis Pugh (tpugh@shore.net)
Date: Fri Aug 18 2000 - 13:06:01 EDT


On Fri, 18 Aug 2000, Tony Tauber wrote:

>
> I should've followed up sooner on what I found out.
> Seems the problem was that the VIPs, the SRAM (not DRAM)
> is carved up into outbound queues per outbound interface
> on the box. The problem came when there were many outbound
> interfaces (eg. CT3s or as you mention PVCs, VLANs) and we
> had only 2MB of SRAM (the max on VIP2-40s).
> The SRAM is carved into equal-sized chunks for these queues.
>
> Take 2048K of SRAM on a CT3IP (which is VIP2-40-based).
> Divide that by 28 channels and each gets 73K.
> Divide that by 114 (if you've got 4xCT3 + 2xPOS on the box, hypothetically)
> and you get about 640 bytes of SRAM buffers.
> 10x64byte packets (or one big packet) and you're done.
>

Ever since I had to back out of a dCEF config on one of my route
reflectors because of VIP memory, we've followed a simple rule of
thumb: max out the memory on the VIP, and max out the SRAM. We're running
dCEF across the board on our 7507s and 7513s, and have absolutely no
problems with it. In light of the problems introduced, it really doesn't
make any sense to skimp on memory.

Of course, if you have a bunch of CT3IPs, it isn't going to help ... :-(

-travis



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:15 EDT