Experiment runtime on IBMQ

Question

I have been trying to get the runtime of my experiment on IBM's quantum computer. I am using the classic stuff, i.e

job = execute(qwalk_circuit, backend='ibmq_16_melbourne', shots=1000)
results = job.result()
results.get_counts()
print(results.data())

I saw on another post that you could see the runtime by using results.get_data(), but that doesnt work anymore, giving me an error that the get_data() attribute does not exist. Is there another way to pull the runtime of my experiment from IBM's quantum computer backend?

My imports, in case I am missing something there:

# importing QISKit
from qiskit import Aer, IBMQ
from qiskit import QuantumCircuit, ClassicalRegister, QuantumRegister, execute
from qiskit import IBMQ, BasicAer
from qiskit.providers.ibmq import least_busy
from qiskit.tools.monitor import job_monitor

Answer 1

I was recently looking for a similar solution. Hope this helps.

job = execute(qc, backend=backend, shots=1024)
results = job.result()
print(results.time_taken)

You can also check all the values stored in result as it is a dictionary by printing it:

print(results)

Here you can check for all the information that is available within the dictionary and you can also observe the value for 'time_taken'

Answer 2

results.get_data() was replaced by results.data(). The new function returns (almost) the same information, but the runtime attribute was removed. As far as I know, there is no official way to get the runtime of your job on the computer.

There are some ways to get it through your own code, but keep in mind these are not official methods of doing so, and the times might not be very accurate. One way would be to call time.time() right when you send your job, and compare it to a time.time() call right when your job completes. However, this would include any time the job spent waiting in queue. You could also try calling the first time.time() call when the job.status() is in a running state, and then call another time.time() once the job completes. This should, in theory, bypass any time the job spends in queue.

However, the feature may be brought back in the future, so I would keep an eye on future release notes as well.