What determines the repetition rate in Google's Weber datasheet?

Question

The second page of the datasheet of Google's Weber system mentions a repetition rate. How is this repetition rate calculated?

https://quantumai.google/hardware/datasheet/weber.pdf

I understand that repetition rate refers to how fast an experiment can be repeated (number of shots per second). I know that to reduce SPAM errors, one way of repeating an experiment is to wait for the T1 decay to ensure that the qubit is reset to |0> before starting the next shot. Other methods like restless measurements can also be used for increasing the repetition rate. My question, more precisely, is whether Sycamore relies on the T1 decay for repeating shots or uses some other technique.

Also, I don't understand how the number of shots affects the repetition rate. The Weber datasheet shows that the typical repetition rate for 2K repetitions is 0.3KHz while it's 2.1KHz for 20K repetitions.

Thanks!

Answer 1

1. How is this repetition rate calculated?

The repetition rate is how many samples can be collected per second. You compute it by collecting some large number of samples and checking how much time it took.

2. [Does Weber rely] on the T1 decay for repeating shots or uses some other technique.

Weber uses active resets between circuit runs. It's the same chip used in the beyond classical experiment, and in the paper's supplement you can find:

• Using the avoided level crossing identified in the root config, determine the operating bias to bring the qubit on resonance with its readout resonator to perform active ground state preparation. We use a 10 µs pulse consistent with the readout resonator ringdown time.

The team is also working on other strategies for performing active reset.

3. I don't understand how the number of shots affects the repetition rate.

The reason the repetition rate is so much higher for large numbers of repetitions is because there are overheads to switching which circuit is running (e.g. network round trips, gate-to-pulse compilation), and you are amortizing those overheads over more runs.