Performance

Token Bucket (Shaping)

Enter the CIR and Bc (or the interval Tc) and I compute the token-bucket model: interval Tc, tokens per interval, sustainable maximum burst and whether an X-byte burst passes. The basis of shaping/policing QoS.

redzilla.cl — shape

Interval Tc

—

Max sustainable burst

—

Verified CIR (Bc/Tc)

—

tokens per second

Tc —

Bc —

Max burst —

Does the burst pass?

—

How it's computed · token bucket

1. The interval Tc = Bc / CIR × 1000 (ms). On each Tc, Bc bits of tokens are added to the bucket, which is capped at Bc.

2. There are 1000 / Tc intervals per second; multiplied by Bc they yield CIR bits/s. Hence CIR = Bc / Tc holds.

3. The sustainable max burst in one shot is Bc bits (= Bc / 8 bytes): whatever fits in the full bucket.

4. An S-byte burst passes if S × 8 ≤ Bc. Under shaping the excess is queued and sent later; under policing it is dropped or remarked. To admit larger bursts, raise Bc (or use Be, excess burst, in dual-bucket models).

Runs locally in your browser · no sign-up · nothing leaves your browser

How it works

The calculator models the token bucket, the mechanism routers and switches use for QoS shaping and policing. From the CIR (committed rate, in Mbps) and the Bc (committed burst, in bits) — or alternatively the Tc interval in milliseconds — it derives the rest of the model: the interval Tc = Bc ÷ CIR × 1000, the intervals per second, the tokens refilled on each one, and the maximum burst the full bucket admits (Bc bits, that is Bc ÷ 8 bytes).

It also verifies model consistency (CIR = Bc ÷ Tc) and answers the practical question: does a burst of S bytes pass? The rule is S × 8 ≤ Bc, evaluated in the best case of a full bucket. The difference between the two techniques is what happens to the excess: in shaping it is queued and sent later (smooths traffic, adds latency); in policing it is dropped or re-marked (no added latency, but packet loss). This is the model behind the Cisco shape and police commands and their equivalents.

Example: 1 Mbps CIR with 8000-bit Bc, does a 1500-byte frame pass?

Interval: Tc = 8000 ÷ 1,000,000 × 1000 = 8 ms, that is 125 intervals per second.
Maximum single burst admitted: 8000 bits = 1000 bytes.
A 1500-byte frame is 12,000 bits > 8000: it does not pass; shaping queues it, policing drops it. To admit it, Bc would need to rise to 12,000 bits or more.

Frequently asked questions

What is the difference between shaping and policing?

Both limit traffic to the CIR with the same token bucket, but they treat the excess differently: shaping stores it in a queue and sends it when tokens are available, smoothing traffic at the cost of latency; policing drops it or lowers its priority (re-marking) immediately. That is why shaping is typically applied outbound toward the provider and policing inbound to enforce a contract.

What Bc value should I configure?

A common starting point is Bc = CIR × Tc with Tc between 8 and 125 ms; many Cisco devices default to a Tc near 8-10 ms for voice and video. A small Bc gives very even traffic but punishes normal bursts (even one large frame may not fit); a large Bc tolerates bursts but allows sharper peaks. Always check that Bc admits at least your largest frame: 1500 bytes is 12,000 bits.

What happens if a burst exceeds the Bc?

It depends on the technique: with shaping the excess bits wait in a queue for the next Tc interval, adding delay and jitter; with policing they are dropped or re-marked to a lower class. The calculator shows by how many bits the burst exceeds and what minimum Bc would let it pass. In dual-bucket models, the excess can be absorbed by the Be (excess burst).

Is a smaller Tc better?

For latency-sensitive traffic, yes: with a small Tc tokens are spread over more frequent intervals and traffic leaves more evenly, which favors voice and video. The cost is that the associated Bc is smaller and large legitimate bursts do not fit at once. A large Tc does the opposite: more burst tolerance and sharper peaks within each interval.

Was this tool useful?

Disclaimer

We take great care to keep every tool accurate and review it thoroughly; even so, we can't guarantee it is free of errors or take responsibility for how the results are used. We recommend double-checking anything critical.

Found an error? Let us know →