Breakdown of Service Time

The service time can be broken into:

  • Any time required by the worker before and after QPU access
  • Wait time in queues before and after QPU access
  • QPU access time
  • Postprocessing (PP) time

Service time is defined as the difference between time-in and time-out for each QMI, as shown in the table.

Keyword in SAPI Meaning
time_received When QMI arrives
time_solved When bundled samples are available

As mentioned in the introduction, service time for a single QMI depends on the system load; that is, how many other QMIs are present at a given time. During periods of heavy load, wait time in the two queues may contribute to increased service times. D-Wave has no control over system load under normal operating conditions. Therefore, it is not possible to guarantee that service time targets can be met. Service time measurements described in other D-Wave documents are intended only to give a rough idea of the range of experience that might be found under varying conditions.

Postprocessing Time

You can apply one or more postprocessing utilities to the raw samples returned by the QPU. As shown in Fig. 55, postprocessing (red) works in parallel with sampling (blue), so that the computation times overlap except for postprocessing the last batch of samples. In this diagram, the time consumed by gathering small batches of samples are marked by vertical blue lines. Within execution of a QMI, gathering the current set of samples takes place concurrently with postprocessing for the previous set of samples (red boxes), which is applied to batches of samples as they are returned by the QPU. As illustrated by Fig. 55, only the time for postprocessing the last set of samples (the rightmost red box) is not overlapped with sampling.

Diagram showing the breakdown of timing in the D-Wave QPU. The entire span of the current QMI is reported as QPU access time. This is divided into two parts: QPU programming time and QPU sampling time. Sampling time may also include postprocessing time if this is enabled for the QMI. A small amount of postprocessing overhead time is also required for each QMI regardless of whether postprocessing is enabled.

Fig. 55 Relationship of QPU time to postprocessing time, illustrated by one QMI in a sequence (previous, current, next).

Postprocessing overhead is designed not to impose any delay to QPU access for the next QMI, because postprocessing of the last batch takes place concurrently with the next QMI’s programming time.

The system returns two associated timing values, as shown in the table below. Referring to Fig. 55, total_post_processing_time is the sum of all times in the red boxes, while post_processing_overhead is the extra time needed (a single red box) to process the last batch. This latter time together with qpu_access_time contributes to overall service time.

Note

Even if no postprocessing is run on a QMI, the returned post_processing_overhead value is non-zero. This is because computing the final energies occurs after samples are returned and is accounted as postprocessing overhead.

Keyword in SAPI Meaning
total_post_processing_time Total time for postprocessing
post_processing_overhead_time Added for the last batch

For more details about postprocessing and how it is handled in the timing structure, see Postprocessing Methods on D-Wave Systems.

“Total Time” Reported in Statistics (for Administrators)

One timing parameter, qpu_access_time, provides the raw data for the “Total Time” values reported as system statistics, available to administrators. Reported statistics are the sum of the qpu_access_time values for each QMI selected by the users, solvers, and time periods selected in the filter.

Note

Reported statistics are in milliseconds, while SAPI inputs and ouputs are in microseconds. One millisecond is 1000 microseconds.