Let's calculate what we're dealing with here. CAR is basically the older version of IOS policing, so all these concepts apply to both.
Committed Information Rate (CIR) = 5,000,000 (5Mbps)
Burst Commit Bucket (Bc) = 937,500
Burst Excess Bucket (Be) = 1,875,000
Time Interval (Tc) = Bc / CIR = 0.1875 s = 187.5 ms
The rate we want to restrict flows to is 5Mbps. The Commit Bucket is 937,500 bytes. The Burst Bucket is 1,875,000 bytes. And the buckets are refilled every 187.5 ms.
As you mentioned, IOS uses a bucket mechanism to restrict how much traffic can pass. It does not smooth the traffic to X% of interface bandwidth over an arbitrary time period! Instead, it allows full access to the bandwidth of the interface as long as you have the tokens to pay for it.
Also, since this is policing, RED/WRED are not in play. RED only happens when there is a queue to manage. There is no buffering/queuing in policing, only in shaping.
Let's deal with the Commit Bucket (Bc) first. Assume that there is no Excess Bucket (Be) for now.
* Commit Bucket Only (Two-Color Policer) *
This is a very strict policer that will only let you send within the CIR exactly; no bursting above. There is only one bucket, Bc. There are two "colors" for traffic, conforming and exceeding.
Time = 0 ms -- The bucket starts out full, with 937,500 bytes worth of tokens in it. Let's say you send 7,500 bytes across the interface. Now IOS decrements the bucket by 7,500 bytes, and the bucket now has 930,000 bytes worth of tokens in it. The traffic sent is considered "conforming" and has the "conform-action" applied to it.
Time = 187.5 ms -- We hit the Tc now, and refill the Bc bucket. 937,500 bytes worth of tokens are added. Any extra tokens spill out and are lost.
Time = 190 ms -- The commit bucket has 937,500 tokens in it. We receive 2,000,000 bytes of traffic. The first 937,500 bytes are transferred fine as the bucket has tokens for it. The remaining traffic is considered "exceeding" and is treated according to the "exceed-action". Remeber, there is no buffering in policing (that's called shaping) - you either transmit, remark and transmit, or drop.
Time = 375 ms -- We hit Tc again, and the Bc bucket is refilled with 937,500 tokens.
* Commit Bucket with Excess Bucket (Three-Color Policer) *
You can optionally add an Excess Bucket (Be). This allows the traffic to exceed the Bc bucket on a temporary basis. The overall CIR should stay the same. This is a three "color" policer: conforming, exceeding, and violating.
Time = 0 ms -- Both buckets (Bc and Be) start out full. Bc has 937,500 tokens, Be has 1,875,000 tokens.
Time = 50 ms -- 2,000,000 bytes of traffic arrives. The router first decrements the Bc bucket tokens. It reduces the Bc bucket to zero. The 937,500 bytes of traffic covered by Bc is considered "conforming" and has the "conform-action" applied to it.
That leaves 1,062,500 bytes of traffic that doesn't have tokens yet. Now the router dips into the Be bucket, and subtracts 1,062,500 tokens to cover the rest of the traffic. These bytes are considered "exceeding" and will have the "exceed-action" applied to it. In your example, the traffic would be dropped, but you could potentially remark or just transmit it.
If you're keeping score at home, Bc now has zero tokens, Be has 812,500 tokens.
Time = 75 ms -- Now, the router receives another 1,200,000 bytes of traffic. The Bc bucket is empty, so no help there. The Be bucket can help, so it covers the first 812,500 bytes of traffic with its tokens, and is now empty. This traffic is considered "exceeding" and will have the "exceed-action" applied to it.
Now the buckets are dry, but there are still 387,500 bytes left to deal with. This traffic is considered "violating" and is always dropped with CAR (You can do other things with it using MQC and the police command with "violate-action").
Time = 187.5 ms -- Now we arrive at the first Tc interval, time to fill up our buckets. A key point is that only Bc worth of tokens are refilled! The Bc bucket is filled up first to 937,500. The Be bucket REMAINS EMPTY.
Time = 375 ms -- It's been quiet, and we make it to the next Tc interval. Bc worth of tokens are added to the Bc bucket. Since the Bc bucket is already full, the excess tokens aren't lost - they're "spilled over" to the Be bucket instead. Now the Bc bucket is full with 937,500 tokens and the Be bucket is partially full with 937,500 tokens.
Time = 562.5 ms -- Quiet still, and we're at the next Tc. Bc worth of tokens are added to the Bc bucket, which is already full. All of it spills over into the Be bucket (which already has 937,500 tokens). The Be fills all the way up to 1,875,000 tokens.
* Final Notes *
Your configuration isn't making use of the Be bucket. You are
rate-limiting/policing using only the Bc bucket, which may have
unintended side effects if the policer/shaper sending data to you
isn't configured identically and isn't in sync Tc-wise.
CAR/rate-limit is very old and deprecated. Consider switching to MQC
and modern QoS to implement this, as it will give you more
information and options.
I totally ignore serialization delay (the time it takes to transmit
data on the line) above, and I'm quite sure the math doesn't work out
in a real scenario. But the concepts are solid regardless of the
exact numbers in use.
* MQC Example *
police cir 5000000 bc 937500 be 1875000
service-policy input PM-FA0/0-IN
* Sources *