Testbed Queuing

About Testbed Queuing

All Job Run Requests and Reservation Requests are actively managed by the testbed queue service in XPRESSO to allow you to queue/stack the requests so they run in sequence based on priority and availability of the testbeds.

Testbed queues are managed automatically by XPRESSO; you cannot directly modify or interact with them but you can indirectly control them using other methods (see below for details). Testbed queues manage testbed time allocation by controlling their prioritization and the dispatching of the request.

NOTE: Job Run Requests with no association to a testbed or topology bypass the priority queue service.

Why Testbed Queuing Matters?

These are the key reasons why Testbed Queuing can help with your test automation requirements:

  1. Provides Automatic Queuing of Job Run Requests: The queuing system allows you to queue/stack Job Run Requests so they run in sequence on the same testbed based on priority and the availability of the testbed. The queuing system also ensures no two objects/actions (for example, different users, Job Run Requests, and device cleans) use a testbed at the same time (this would nullify any test results).

  2. Ensures Efficient Use of Testbed Resources: The queuing system ensures the efficient use of resources with the option to queue Run Requests against all associate testbeds in anticipation of running it on the first available testbed, or on each testbed (if the option to "Execute on all Testbed" was selected when configuring the Job Request).

  3. Provides Testbed/Device Utilization Stats: Prior to implementing testbed queuing in XPRESSO, determining your testbed/device utilization was ad hoc leading to either no usage stats or inaccurate stats. Since testbed queues are now managed automatically with XPRESSO, this can help you determine which testbed/devices are heavily-used, under-utilized, or not-at-all.

Testbed Queuing Rules

XPRESSO applies the following testbed queuing rules to all Job/Reservation Requests:

  1. Each testbed has its own unique queue.

  2. All Job or Reservation Requests are placed in their respective testbed queue.

  3. The testbed queue dispatches pending requests based on the following criteria:

    • Queue Dispatch Priority: When the priority queue is ready to dispatch the next request, it prioritizes higher priority items over lower priority items independent of how long the request has been in the queue. As long as a Job/Reservation Request has a higher priority, it will be dispatched first.

    • First-in, First-out basis (FIFO): This is used when the priority of all requests are the same.

  4. The system default for all queued items is P4. Group Admins can change/override the default setting in Group Preferences.

NOTE:
Although Group Administrators set the default value for Group Preferences, you can select a priority setting that meets your immediate needs which overrides the default setting.

Example Testbed Queue Priority

Example

Current Queue:
    REQ0000134(P4)     REQ0000135(P2)    REQ0000136(P4)    REQ0000137(P0)

Dispatch Order:
    1. REQ0000137(P0)
    2. REQ0000135(P2)
    3. REQ0000134(P4)
    4. REQ0000136(P4)

Supported Operations on Queued Requests

You can perform the following operation on Job/Reservation Requests:

  • Change the priority of the Request
  • Cancel the Request

Methods to Control Testbed Queues

You can use the following methods to indirectly control the behavior of Testbed Queues:

  • Set the priority of a Job Run Requests: Queues are ordered (listed) by priority ranging from 0-5 where P0 presents the highest priority and P5 represents the lowest priority. Requests are then prioritized by submission time within each priority class.

    NOTE:
    Reservation Requests are set at priority level 4 and cannot be changed.

  • Set the Maximum Queue Retention time on a testbed: Specify the maximum amount of time the Request can wait in the queue. When this time is reached, the Request is dropped (therefore removed from the priority queue) and tagged with an EXPIRED operational state.

  • Reserve a testbed in advance: You can reserve a testbed for a specified time period for manual testing, or automated runs with no interruptions. Requests from all other users will be placed in the Queue until your testbed reservation time expires.

  • Disable the Testbed: You can off-load Job/Reservation Requests to associate testbeds if more than one as selected when configuring the Job Request. Otherwise the Job/Reservation Requests will remain in the testbed Queue until the Queue Retention timer expires and the requests are removed from the Queue.

Refer to the following topics for other related testbed queuing information: