QuNetSim Concurrent in-flight `send_qubit` (K>1) delivers \~0 qubits; SEQ OK. EPR fails with `Qid doesent match id!`

[onursami]

Labels: bug backend concurrency eqsn question

Summary

• Single-stream (SEQ): stable, 0% drop, p95 ≈ 332→388 ms for 10→40 qps.

• Concurrent in-flight (K>1) or multi-sender (M>1): Bob receives almost no qubits.

  • Example (M=3, N=60, interval=50 ms, recv_wait=5 s):

    • workers=1 → Sent=180, Recv=2, Drop=178 (~98.9%)
    • workers=4 → Sent=180, Recv=5, Drop=175 (~97.2%)

• EPR/Teleportation: intermittently fails with:

  ValueError: Qid doesent match id!
  ... eqsn_backend.py:229 receive_epr
  Exception: failed to get EPR
  

Environment

• Python 3.10.18, Ubuntu (VM/bare metal)
• QuNetSim from repo (editable install), EQSN workers tried: 1 and 4
• Measurements use monotonic time (perf_counter_ns)

Minimal Repro (concept)

1. Alice→Bob; send K=5 in-flight qubits (no per-send wait); Bob loops get_qubit("Alice", wait=...).
2. Also tried “consumer” classical reads (get_next_classical) with SID de-dup + FIFO pairing.
3. Result: N_recv≈0; all headers time out (100% drop).
   (K=1 works as expected.)

Expected vs. Actual

• Expected: With K>1, higher p95 and some drops, but N_recv ≈ N_sent − drops.
• Actual: With K≥5 (or multi-Alice), delivery collapses (≈100% timeout). SEQ remains fine.

Questions

1. Is multiple in-flight qubits per link (K>1) supported? Any required ACK/back-pressure?
2. Classical API semantics: is get_next_classical(sender, wait) the intended consumer? Any caveats with threads?
3. Known fix for Qid doesent match id! in EPR/teleportation?
4. Do more EQSN workers enable true quantum concurrency, or is serialization expected?
5. If K>1 per link is not supported, is multi-sender parallelism the recommended pattern?

Happy to share full logs/CSV and a tiny runnable repro script if helpful.

qns_seq_results.csv.txt