Latency Requirements

Definition

A latency requirement is a performance requirement that specifies a minimum amount of the performance quality subfactor latency.

Objectives

The typical objectives of a latency requirement are to:

• Ensure that the application or component does not take too long to complete a user task or use case path.
• Specify the required temporal aspects of inputs and outputs (i.e., event streams):
  • Periodic event streams are streams in which the time intervals between events are equal.
  • Probabilistic event streams are streams in which the time intervals between events vary according to some stochastic distribution.
  • Sporadic event streams are event streams in which the time intervals between events cannot be smaller than specified minimum time intervals.

Measurements

Latency requirements are typically specified in terms of the following measurements:

• The maximum acceptable time for a service request.
• The maximum acceptable average time for a service request.
• The temporal type of associated event streams.

Examples

The following are typical examples of latency requirements:

• “The application shall display temperature sensor readings every 5 seconds.”
• “The average time that the application uses to process pressure sensor readings and display the result shall not exceed 1 second.”
• “The maximum time that the application uses to process a customer purchase order containing up to 10 different products that are currently in stock shall not exceed 10 seconds.”
• “Upon receiving a request for the customer’s account information, the application shall display that information to the customer in 5 seconds.”

Guidelines

The following guidelines have been found to be useful when producing latency requirements:

• The scope of a latency requirement can be:
  • A business enterprise
  • An application
  • A component
  • A center
• Latency requirements typically involve end to end execution of a specific task (e.g., a system operation or path through a use case).
• Latency requirements are typically different for hard realtime and soft realtime applications:
  • Hard realtime systems:
    • Have very tight time frames (e.g., milliseconds).
    • Are typically hardware driven (e.g., process control or avionics).
    • Physics will not wait (i.e., the right answer too late is the wrong answer).
    • Deadlines cannot be missed.
  • Soft realtime systems:
    • Have less restricted time frames (e.g., seconds).
    • Are typically human driven (e.g., eCommerce, information systems).
    • People will wait (although not forever).
    • Deadlines can be missed.
• Latency requirements are different from and not to be confused with the architectural mechanisms that may be used to implement them:
  • Increase physical concurrency by adding redundant servers, memory, and networks.
  • Selecting an appropriate load balancing algorithm.
  • Increasing server clock speed.
  • Increasing network bandwidth.
  • Selecting an appropriate scheduling policy.
  • More computationally efficient algorithms.
  • Changes in sampling rates.
  • Maintaining local copies of data.
• Latency requirements can also be indirectly specified as:
  • Governmental constraints such as compliance with section 508 of the United States Government Rehabilitation Act of 1973, as amended (29 U.S.C. 794d).
  • Industry standard constraints such as compliance with the World Wide Web Consortium Web Latency Initiative Guidelines.