|
| | GapRate () |
| | Construct a GapRate object with initial rate 0.
|
| |
| | GapRate (uint64_t r) |
| | Construct a GapRate object with initial rate r.
|
| |
| uint64_t | rate () const |
| | Return the current rate.
|
| |
| void | set_rate (uint64_t r) |
| | Set the current rate to r.
|
| |
| void | set_rate (uint64_t r, ErrorHandler *errh) |
| | Set the current rate to r.
|
| |
| bool | need_update (const Timestamp &ts) |
| | Returns whether the user's rate is behind the true rate.
|
| |
| Timestamp | expiry () const |
| | Returns a time when the user's rate will be behind the true rate.
|
| |
| void | update () |
| | Increment the user event counter.
|
| |
| void | update_with (int64_t delta) |
| | Increment the user event counter by delta.
|
| |
| void | reset () |
| | Resets the true rate counter.
|
| |
A helper class for implementing a uniform rate.
The GapRate class helps its user implement a process with a uniform rate: a process in which one user event happens every T seconds. GapRate is designed to efficiently model high rates. (Contrast this with Timer, which can serve a similar function at low rates.)
GapRate is not a great choice for limiting the rates of external processes. See TokenBucketX, a token bucket rate limiter.
GapRate models an underlying "true" rated process with the correct rate. It also keeps a counter, maintained by its user via the update() method, that measures the progress of the user's rated process. The needs_update() method compares this counter with its expected value, which is determined by the true rated process. If the user's rated process is running behind, then needs_update() returns true; the user should trigger an event and call the update() method. If the user's rated process is just right or is running faster than the true process, then needs_update() returns false; the user should not trigger an event.
Creating a non-bursty rate can be expensive and difficult. GapRate attempts to create a non-bursty rate using timestamps and some interesting microsecond-based arithmetic. External factors can cause scheduling hiccups where GapRate is not called as much as expected. GapRate compensates for hiccups: the user's rated process may fall up to a full second behind the true rated process, then catch up in a burst. More than one second's worth of lag is ignored.
The maximum rate GapRate can implement is MAX_RATE events per second.
- See also
- TokenBucketX, Timer