Thank you for all the analysis.
The driver you point to is actually legacy code. libbladeRF now uses libusb. The code that controls the streaming is in https://github.com/Nuand/bladeRF/tree/m ... /streaming, which uses callbacks provided by https://github.com/Nuand/bladeRF/blob/m ... b/libusb.c.
It intends to keep 16 URBs queued up. It initially queues up all 16, and then resubmits 1 more when its transfer complete callback is called. Is this a reasonable method for queuing URBs?
I did a trace on a Pi 4: . It was too large, so I had to truncate the last ~10000 lines.
Doing on both files shows the initial 16 URBs enqueued with about 30 us between. After that, a new one is enqueued every ~800 us. I don't see a relevant difference between the Pi 4 and Pi 5 traces.
Looking at the discontinuities in the capture from the Pi 5 at 20 Msps, I see the following:
- Bytes 0..77823: Received 77824 bytes
- Bytes 77824..896959: Missing 819136 (not multiple of 1024)
- Bytes 896960..925631: Received 28672 bytes
- Bytes 925632..930975: Missing 5334 bytes (not multiple of 1024)
- Bytes 930976..83886079: Received 82955104 bytes
This would indicate to me that the driver is late to poll the bladeRF in these instances, perhaps because it doesn't have any URBs enqueued. Would you agree?
The driver you point to is actually legacy code. libbladeRF now uses libusb. The code that controls the streaming is in https://github.com/Nuand/bladeRF/tree/m ... /streaming, which uses callbacks provided by https://github.com/Nuand/bladeRF/blob/m ... b/libusb.c.
It intends to keep 16 URBs queued up. It initially queues up all 16, and then resubmits 1 more when its transfer complete callback is called. Is this a reasonable method for queuing URBs?
I did a trace on a Pi 4: . It was too large, so I had to truncate the last ~10000 lines.
Doing
Code:
grep xhci_urb_enqueue ~/trace-20M | grep ep1in-bulkLooking at the discontinuities in the capture from the Pi 5 at 20 Msps, I see the following:
- Bytes 0..77823: Received 77824 bytes
- Bytes 77824..896959: Missing 819136 (not multiple of 1024)
- Bytes 896960..925631: Received 28672 bytes
- Bytes 925632..930975: Missing 5334 bytes (not multiple of 1024)
- Bytes 930976..83886079: Received 82955104 bytes
This would indicate to me that the driver is late to poll the bladeRF in these instances, perhaps because it doesn't have any URBs enqueued. Would you agree?
Statistics: Posted by Steve Ochs — Thu Aug 08, 2024 4:33 pm
