[c-nsp] 3560 buffering

[Jeff Bacon]

I use a number of 3560Gs as distribution switches in my co-lo farm, with
4G uplinks to 4948s. The load is fin-svcs, and can be quite bursty,
tends to be a lot of small packets, but with a mix of larger stuff and
standard file transfer etc.

I've been seeing a number of output drops on the etherchannel ports to
the 4948s, as well as to the servers themselves.

What's an output drop mean, in a 3560 context? Queue to the host is
full? Host interface already maxed out, "there was a packet on the wire
being transmitted to the host, so sorry I'll drop the packet"? Or can it
be an ingress/switching decision of some sort? 

How deep is the individual buffer/ring on a gig PHY? Or is it buffered
per-ASIC? (Doesn't seem to be) 

Is there a way to tell the 3560 to buffer more aggressively?

The 4948s don't really have any of these problems, and when I moved some
of the hosts to the 4948s which were showing output drops (to the server
from the switch), the problems went away, so either the 4948 buffers
better, transmits better, or just doesn't log as well. (Yes, the 4948 is
a better switch. But it's not like the 3560s are oversubscribed either -
if they're doing 1Mpps at peak it'd be a miracle. It's a finsvcs load
but it's not THAT intense, just bursty.) 

Then there's this mysterious output from "sh cont eth port-asic stat"
wherein I get a number (not huge) of "RxBuffer Drop DestIndex Cou". Huh?
Not documented anywhere; trying to pull info out of TAC but it's a slow
process. 

Thanks,
-bacon