Daemon - bytesPerMinuteResourcePool

 

Description

A Daemon that keeps track of the number of bytes moved on some conceptual "channel." This daemon works in conjunction with throttleBytesPerMinute juggler. The pool has a name. As throttleBytesPerMinute jugglers do their work, they "ask permission" from the pool to move data. The pool grants permission or delays permission so as to limit the rate of total number of bytes moved within the pool.

See Resource Management -Model & Implementation for a general description of the PAM consumer-resource model.

 

Configuration Variables

bytesPerMinuteBudget
Defaults to 100000. Identifies the limit in bytes per minute through this pool. If the budget is changed when there are member throttleBytesPerMinute jugglers already waiting they will recompute their delays based on the new budget! If the budget increases, outstanding delays get shorter. If the budget decreased, outstanding delays get longer.

bytesPerMinuteConsumption

A number that identifies a running average of how many bytes per minute have been moved through this pool. Writing this value will reset the history for this agent and affect the running average. A new running average is computed when this attribute is read - so generally this attribute's value will always change.

bytePerMinuteManager

Defaults to "eightProductAverage". With this value statistics are based on a sliding window that includes the last 8 products sent by throttleBytesPerMinute jugglers that are part of the pool.

Can also be set to "thirtyProductAverage". This causes statistics to be based on the last 30 products.

How it works

Each instance of a bytesPerMinuteResourcePool keeps track of its own statistics. When a member throttleBytesPerMinute requests permission to pass a product the pool looks at a history of products sent and computes a current "consumption" of bytes per minute. If the the current "consumption" exceeds the budget then the requesting throttleBytesPerMinute agent delays passing the product until enough time has passed so that the "consumption" is under budget.

There may be multiple instances of throttleBytesPerMinute jugglers that are memebers of a bytesPerMinuteResourcePool instance. For this reason if the pool's budget is exceeded all members wait and then ask permission to send again at such a time as the computed consumption drops below the budget. In general only one throttleBytesPerMinute juggler will get permission to send and all the others will have to wait again.

On the other hand, if the current consumption is below budget the throttleBytesPerMinute juggler will be given immediate permission to pass its product.

The pool uses a "sliding" window to compute its statistics. By default the window covers the last eight products. The history includes the time at which each product was passed and the product's size. A window of eight is appropriate for infrequent file transfers. A window of thirty is more appropriate for frequent products of small size.

There is one characteristic of the sliding window approach that is counterintuitive. This can be illustrated by an example. Assume that the budget was set to 1000 bytes-per-minute and the window size was eight (bytePerMinuteManger "eightProductAverage"). Assume that the last eight product transfers happened once per day and were one byte each -- the pool is clearly under budget.

Look at what happens now if there was a succession of eight products spaced by 5 seconds, with each product equal to 1000 bytes. The first 7 of these would pass immediately because the consumption statistic would be based on 7001 bytes averaged over one day, which is clearly under budget. However, the eighth product would see 8000 bytes averaged over 35 seconds which is clearly way over budget. Thus the eighth product would be delayed approximately 7 minutes to allow the consumption to drop below budget.

This behavior is a bit harsh and may be modified in the future. Despite this counterintuitive behavior the pool does do its job of throttling data flow within its time window.

 

 

  

Revised: 23 April 1999