[Discuss-gnuradio] Threaded model for USRP2 source
From:
Douglas Geiger
Subject:
[Discuss-gnuradio] Threaded model for USRP2 source
Date:
Thu, 23 Jul 2009 11:13:59 -0400
In my messing around with a custom USRP2 source block (since I'm trying to get time-aligned samples out from multiple USRP2's), I've run into what is probably the main issue with getting full-bandwidth samples (-d 4 => 25MS/s) out of multiple USRP2's: dropped sample frames at the host PC. While I'm (currently) content to work with lower sample rates to the PC, eventually I'm going to want the full 25MS/s out of two (or more) USRP2's. So, I'm been giving some thought to getting that work. On my development machine I've got many cores (two quad-core Xeon's) - and for the most part I've got plenty of CPU left - i.e. my thread that's handling samples from the USRP2's is using 100% of one of the cores, and any other blocks I may be using are using some percentage of the other cores - but my main limit is the single thread handling the USRP2 source block. So, the apparently obvious solution is to split the source block into multiple threads, right? It seems to me that the obvious thing to do is have separate threads doing the work of the rx_handler code - which just constantly check if samples are available, and put them in a queue/vector/something (perhaps a deque would be best - since I can add to the end, and pop off the front...), and the main thread of the block then just polls the queue/etc. for incoming samples, rather than calling rx_handler only when the scheduler calls the work() function.
So, while this makes sense to me, I figured I'd check with the list to see if anyone else has tried this - and if they have suggestions/comments/pitfalls to avoid, etc. If not, I'm happy to plow ahead and find out just how much trouble I'm in for here. The boost library does seem to have nice functions for handling threads, so I've started messing around with them, but this is a fairly new area for me. Comments welcome!
Doug -- Doug Geiger address@hidden