There are regular discussions or rather questions regarding how the Paced Loop works in IBM Rational Performance Tester (RPT).

The key attributes are:

1) Pacing for trans-active behavior, expressed as N iterations per T time unit.

2) Delay randomly between iterations.

3) Delay before the first iteration.

**Delay before the first iteration**:

This option results in each user executing a delay before beginning the first iteration's work. This delay, and only this first delay, is a uniform random delay bounded between 0 and the duty cycle. The duty cycle is defined as the maximum amount of time allowed for performing one iteration of work, equivalent to the reciprocal of the loop's iteration rate.

As further illustration, consider a setting for the first attribute that specifies 120 iterations per hour. Breaking down further, the attribute calls for 2 iterations per minute, or 1 iteration every 30 seconds. The maximum amount of time to perform one iteration of work is 30 seconds. The duty cycle in this case is 30 seconds.

A uniform random delay with a duty cycle of 30 seconds means that delays will range from 0 to 30 seconds, and on average, virtual users will delay 15 seconds before beginning work for the first iteration.

Expressing the calculation of this delay in pseudo code and using units of milliseconds (low=0 & high=30000):

** Delay = (int)(nextDouble() * high)**

**Delay randomly between iterations**:

Once users begin paced loop iterations, we attempt to deliver the specified transactive behavior. If the behavior calls for 120 iterations per hour then each user should be executing 120 iterations per hour. Without the delay between iterations and without the delay before first iteration the users should be in lock step executing at the rate specified.

If you specify that you want to delay randomly between iterations, a negative exponential delay over the duty cycle is performed. If the duty cycle is 30 seconds the average delay should be 30 seconds. The variance can result in delays well in excess of the duty cycle.

The negative exponential delay can be described in pseudo-code as:

**-dutycycle * Math.log(nextDouble())**

Paced loops take into account time spent doing the work of the iteration and they try to "catch up" if falling behind due to driver sluggishness.

The way this happens is that you always know when a particular iteration was supposed to start. You know what was calculated for the delay, and know when the next iteration should start.

Probably best to think about how it works using the simplest example, which is a fixed rate with no initial delay and no random delays. If the duty cycle is 30 seconds work for each iteration would begin in terms of "time in test" as follows

0 --- 30 --- 60 --- 90 --- 120 --- 150 ---

with work being done at 0 seconds time in test, 30 seconds time in test, etc.

The delay would be 30 seconds if work took 0 seconds. But, the work of course takes some amount of time greater than 0 seconds. So, each calculated delay, random or fixed, is adjusted according to when the next iteration should begin and the current time in test.

In the example above, if the first work iteration took 3 seconds, the actual delay is calculated this way:

next = last + delay

next = 0 + 30

next = 30

last = next

adjusted_delay = next - time_in_test

adjusted_delay = 30 - 3

adjusted_delay = 27

If at the second iteration, work takes 6 seconds:

next = last + delay

next = 30 + 30

next = 60

last = next

adjusted_delay = next - time_in_test

adjusted_delay = 60 - 36

adjusted_delay = 24