[c-nsp] 6500 SUP720 High Latency and Jitter issues

[Rodney Dunn]

Having a fallback path to software switching when the
hardware switching path can't handle it allows for
more flexibility at the expense of performance.

I'd very much like to see the 75xx finally make the
transition to a full dCEF box to eliminate the complexity
of the punt path but I can promise you that will never
happen.

The 76xx in that context is more like a 75xx than a GSR.
The GSR doesn't have a punt path to the main CPU that
handles the control plane work but the 76xx does. There
is a punt path on some LC's that have HW forwarding
capability to the LC CPU for packet forwarding. Same issue
applies there that performance quickly goes down if
that happens.

Being better or worse is all about which side of the fence
(both internal to Cisco and outside in customer land) you
are on. Some deployments work just fine in the software
path (ie: the rate of packets for a given feature are low
and the high volume traffic that justifies the bigger box
is hardware switchable).

The hardware implementations are getting better and more
flexible but as always never fast enough to make everyone
happy.

Troubleshooting capability can never be too good to help
isolate this type of thing. We can always do better as
I'm sure any vendor can.


Rodney


On Thu, May 26, 2005 at 05:00:22PM +0200, Simon Leinen wrote:
> Jared Mauch writes:
> > On Wed, May 25, 2005 at 11:26:54PM +0200, Gert Doering wrote:
> > [...] this is part of knowing your platform.  The '76k' (i've
> > renamed it since it's confusing to have the 7600/6500 name, i
> > encourage everyone to call it by this name :) is a software based
> > platform, with 'mls' hardware assist for some features.
> 
> I don't think that this is a useful way to look at it.  Besides the
> general confusion of the "software vs. hardware" terminology, I find
> it more useful to think of the Catalyst 6500/7600 OSR (76k? Shouldn't
> you call it 7k6?) as a "hardware-based" (ASIC/TCAM) platform, which
> has a general purpose CPU that can be used to switch packets "in
> software".  But software switching should remain the absolute
> exception.
> 
> > If you add a distributed linecard, they will be handled in the
> > linecard (in most cases) that can be seen by doing a 'sh cef line'
> > to know what slots are likely to be hardware switched.
> 
> > 	This is similar to the 7500, where if you had a VIP linecard,
> > packets would (if configured for dcef) be handled in a distributed
> > fashion, but with older linecards, it would be handled on the RP.
> 
> Yes, DFCs are similar to VIP in the sense that you can use them to
> distribute the forwarding work.
> 
> But a DFC always offloads forwarding work from the PFC, and a VIP
> offloads forwarding work from the main (RSP) CPU.  And a PFC/DFC can
> switch 20-30 Mpps, while a VIP or an RSP - and the general-purpose CPU
> on the MSFC - can handle something like 100-200 kpps(?).
> 
> So DFCs are nice if you are starting to reach the 30 Mpps limit of the
> PFC (our OSRs all switch <500 kpps, so we don't have a single DFC),
> but they don't help when your MSFC is loaded.  On the other hand, the
> MSFC shouldn't do anything other than run BGP, OSPF/IS-IS, SNMP and
> the CLI.
> 
> So for you the 76k is a distributed software-based platform that can
> use "hardware" to speed up some frequently-used features (such as IP :-).
> 
> For me the 7K6 is a centralized hardware-based platform that has some
> software so that I can log into it and play with it, and that can be
> extended with distributed hardware forwarding ("decentralized") if
> necessary.
> -- 
> Simon.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/