Hello Remco: If benchmark_rate runs fine at the target rx rate, the processing speed of the CPU is probably the main bottleneck. If you want to test it further, you can check the "maximum throughput" of your software (maximum rx rate that your software can keep up).
If your program is in GNU Radio, one thing that you can do is replacing the "USRP Source" to a file source with pre-recorded data (or maybe a random source, if the performance of your flow graph is not affected by the incoming data), and attaching a "Probe Rate" and a"Message Debug" right after that. If the processing rate, printed to stdout, is slower than the target sampling rate, then your your CPU is not keeping up. If it is keeping up, the problem could be caused by some other issues, including but not limited to two-clock issues, USB controller issues, and USB connection issues (faulty USB 3.0 connection; it does happen!). You should be able to do something similar even if your program is not in GNU Radio (I don't have directions for that, though). In my experience, Ethernet-based USRPs (like N200s and X300s) are indeed a bit better at this. However, if the bottleneck is caused by the software, then replacing the SDR board won't fix the problem. Regards, Kyeong Su Shin ________________________________ 보낸 사람: Remco Vink via USRP-users <[email protected]> 대신 USRP-users <[email protected]> 보낸 날짜: 2019년 8월 28일 수요일 오후 4:00 받는 사람: [email protected] <[email protected]> 제목: [USRP-users] Overrun on USB vs Ethernet All, I am experiencing some issues with overruns stopping the streamer of our USB B200 devices. Currently the computers in use are not the fastest in their kind, but I am wondering where the limitation is coming from. I haven't found a way to measure the throughput of the USB, so it might either be the USB controller or processor which is not fast enough to handle all the data. The benchmark_rate seems to run fine at the rx_rate the program is running on. If for instance I would to switch to a network based device and have the connection over ethernet, would this possibly fix the issue or would the processor or some other bottleneck still arise. Would like to hear your thoughts on this overrun and most likely bottleneck problem.
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
