Understanding qpu_access_time

Hello,

I'm trying to determine internet latency by making use of "qpu_access_time" supplied by the sampleset
timing info, which I understand is in microseconds. However, the value supplied appears to be greater
than the time measured for calling "sampleset = sampler.sample_ising(h, J, num_reads=nreads)".

For example, I'm finding that the code below always gives negative values for the internet latency.


start_anneal = time.perf_counter_ns()
sampleset = sampler.sample_ising(h, J, num_reads=nreads)
anneal_time = time.perf_counter_ns() - start_anneal

qpu_access_time = sampleset.info['timing']['qpu_access_time']*1000.0
internet_latency = anneal_time - qpu_access_time

Please could someone tell me what I'm doing wrong here.

0

Comments

4 comments
  • Hello,

    Are you able to provide a complete minimal code example that demonstrates the behaviour you are describing? 
    It is difficult to determine what exactly is happening without knowing which solvers and parameters are being used, etc. Please remember to obfuscate your API Token for security purposes.

    It is possible that the call to the sample_ising function is being made asynchronously meaning that the anneal_time value in your code example above is being recorded before the sampleset has returned.

    Moving the second call to perf_counter_ns to after accessing sampleset.info might resolve the issue you are seeing.

    Hopefully this is helpful. Please let us know if this resolves your issue. 

    0
    Comment actions Permalink
  • Thank you DavidJ!

    Yes, some implicit asynchronicity was the problem.
    Accessing `sampleset.info` before the second call to `perf_counter_ns` now results in positive latencies.

    One follow up question, just before I call `sampler.sample_ising()`, there is this line of code,
    `sampler = EmbeddingComposite(DWaveSampler())`.

    Is there any communication with the remote QPU as a consequence of this preceding statement?

    The DWaveSampler constructor will be checking the DWAVE_API environment variables to see
    which QPU I'm using, but are the details re the topology required to do the embedding held locally
    within the Ocean SDK?

    For example, if using Advantage_system4.1, does the target graph come from 'dwave_networkx.pegasus_graph(16)'?

    Thanks again,
    Michael

    0
    Comment actions Permalink
  • Hi Michael,

    EmbeddingComposite takes in a given arbitrary graph and then maps it to the graph of the solver provided by DWaveSampler.

    Each D-Wave solver has a slightly different working graph, which is fetched during the DWaveSampler constructor call.

    This means that the unique topology of a specific DWaveSampler is needed in order to do this mapping.

    The call to dwave_networkx.pegasus_graph() produces an idealized graph with all of the qubits an couplers available.

    It is possible to get qubit and coupler information, and more, from the solver properties returned in the DWaveSampler object as in the below example, though this particular information is a bit tricky to parse manually due to the large number of values returned:

    from dwave.system import DWaveSampler
    sampler = DWaveSampler()
    sampler.properties["qubits"]
    sampler.properties["couplers"]

    I hope this was helpful. Please let us know if you have any questions.

    0
    Comment actions Permalink
  • Hi David,

    Thank you very much for those details.
    It's clear that the best approach is to move the `DWaveSampler()` constructor before the timing loop, especially as for my purposes that call only needs to be made once.

    Best wishes,
    Michael

    0
    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post