According to

http://www.cisco.com/en/US/products/hw/switches/ps646/products_tech_note0918 6a00800feff5.shtml

To sustain the specified traffic rate, the burst should be no less than the sum of the following equation:

Burstmin (bits) = Rate (bps) / 8000 (1/sec)

For example, calculate the minimum burst value for sustaining a rate of 1 Mbps. The rate is defined as 1000 Kbps, so the minimum burst needed is the sum of the following equation:

1000 (Kbps) / 8000 (1/sec) =125 (bits)

Also here is a good link with regards to QoS Caveats

http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration _guide_chapter09186a008007d733.html

You can shape in and out, using different policy maps (with limitations on shaping outbound using acls). One approach is to shape on the ingress port, and then apply another policy map inbound on your uplink(s).

I struggled with QoS on the 3550 for a while, due to the fact that my monitoring software (real-time 1/sec snmp) was showing the port I was monitoring as spiking well above the threshold I had set. Be aware that you will not be able to see whether your policy is having any effect if you are trying to look at the traffic statistics of the port. This is because the interface stats will always show the result before policing. One way to do it is to look at your upstream port, but you will have to try and separate the individual customer from the aggregate which is nigh on impossible (other than adding up all of your QoS values for all ports and ensuring that the aggregate value conforms).

On the upside, I can at least see if a customer is consistently sending more traffic than their shaped rate, and if so pass that information to sales, as they would likely want to upgrade.

Thanks,

Tim