Estimators ---------- An estimator tells us has fast data is flowing. Typically it is reported in bytes or bites or bits per second. Queuing disciplines use estimators to calculate how much data is flowing through the link. Policing options on filters can do the same thing. Although the concept is intuitively simple it is not the easiest thing to calculate, particularly when the traffic is bursty. To calculate it the traffic control engine uses a "Exponential Weighted Moving Average", or EWMA. Fortunately it is not as complicated as that name makes it sound. The syntax for an estimator is: estimator Both and are time intervals. During each the estimator takes a measurement of how much data was sent during the interval. So after a while the estimator ends up with a string of measurements like this: M[T], M[T-1], M[T-2], M[T-3] and so on. Here M[T] is the estimate for the last interval and M[T-1] is the estimate for the previous interval, and so on. Once you have a string of these estimates you could just average them, but that takes too much storage and time. Instead what happens is each interval is decayed. It has a half life, in just the same way a radio active material has a half life. Lets say the half life is equal to the . What we would end up with is a series like this: M[T] + M[T-1]/2 + M[T-2]/4 + M[T-3]/8 + M[T-4]/16 + ... Notice that as a measurement ages it rapidly looses its effect on the final figure. This figure can then be scaled appropriately to yield a estimate for the flow rate. Despite the long looking formulas the choosing an appropriate and half life is relatively easy. Lets say you had a bursty data source, so you wanted to get the average rate in any 6 second period. Choose a half life slightly smaller than the period you want to measure, 4 seconds say. Then choose an interval that gives you a few samples in that period. 4 is a good number of samples, so the would be 1sec. Simple really. OK, now for the icky details. You don't get much a choice here. It can be one of 250msec, 500msec, 1sec, 2sec, 4sec or 8sec. You can enter other values, but they will be "rounded" back to one of these. This is twice what I called the half life above. The minimum value is the double the , and it goes up in powers of 2 from there. So if you had a of 250msec values for the could be 500ms, 1sec, 2sec, 4sec, 8sec, 16sec, ... Again you can enter other values but they will be "rounded" to one of these. There are places (notably the cbq queuing discipline) that get you to enter a half life in a different form. This time the half life is expressed as the value representing the number of intervals the half life spans. For example, if your interval is 2 seconds and your half life is 16 seconds, then the half life spans 8 intervals. Being allowed to enter 8 would be nice, but you aren't. Instead you must enter the log to base 2 of that number, plus 1. log_base_2(8) is 3 (because 2**3 equals 8), so you would have enter 4 (3+1) in this example. I did say it was icky. An estimator is added at the start of the "tc filer" command line, like this: # tc filter add dev MYDEVICE parent 1:0 protocol ip prio 1 handle 1 \ estimator 1sec 8sec fw \ classid 1:1