Hello Keith, Sorry for the long silence - this problem really needed mulling over in my head, and then I postponed that... So, yes, I'd see why you want fine-tuned control over threading.
Would modifying UHD be an option for you? I could imagine the following to be a viable approach: 1. in zero_copy_recv_offload_impl, add a new setter for _recv_thread' CPU affinity 2. in x300_impl, add a new property tree property with a subscriber that calls that setter In effect, you'd then have a new property that you'd see with `uhd_usrp_probe --tree`, and you could access that from your software to change the right thread's properties. Does that sound like it makes sense to you? Best regards, Marcus On Tue, 2018-05-22 at 16:15 +0000, Keith k wrote: > Hello Marcus > > I'm trying to run 16 N200s with LFTX/LFRX boards. I want to use all > 16 TX channel and 20 RX channels at 10 MHz sampling rate. I will be > streaming continuous on RX and sending bursts on TX. The problem I'm > having is that the RX threads really don't like being preempted too > often or they go into a unstable state where they continually drop > samples. I've got a computer with a core i9 and I've isolated 70% of > the cpu cores purely to my process, but when it comes to scheduling > the threads the best I can do is evenly distribute them since I'm not > aware of a mechanism to get the TID of only the UHD RX threads. Using > isolcpus and taskset with basic round robin cpu affinity, I can get > all 16 TX channels and 12 RX channels working for a period of a few > hours, but I think if I could properly schedule the RX threads, I > would be able to get them all working without dropped samples. In > theory the fork would work for me since I could use a child process > for only TX or RX threads and I could manually schedule them, but > practically I know there would be problems with the multi-usrp > object. > > Right now I'm scheduling using command line utilities once my > application is running, but I've now been considering querying the OS > for TIDs before and after each streamer is created from within my > application. I should be able use this information to isolate which > set of threads are for RX or TX. Do you have any thoughts on the best > approach to scheduling for UHD or operating high data rate multiusrp > configurations? > > On Sat, May 19, 2018 at 9:05 AM, Marcus Müller <marcus.mueller@ettus. > com> wrote: > > Hi Keith, > > > > in principle, you could continue using the multi_usrp in **one** of > > the processes. The real problem stems from the question of who > > inherits the sockets (in the case of network USRPs), the USB > > handles, or kernel ring buffer handles. > > In the end, only one process might react to packets coming from the > > USRP. Also, this is C++, so if you don't watch out in your main > > process, and your multi_usrp loses scope, its destructor would be > > called, with devastating effects on the state of your USRP. > > > > On the other hand, there is, at least as far as I can remember from > > the top of my head, nothing to react to until you start a streamer. > > But I wouldn't recommend relying on that as kind of API; I don't > > think we guarantee usability of a multi_usrp after forking, but the > > last word on that is Martin's. > > > > Maybe if you described your use case, we could chime in with > > approaches. > > > > Best regards, > > Marcus > > > > On 14 May 2018 18:09:51 GMT+02:00, Keith k via USRP-users <usrp-use > > r...@lists.ettus.com> wrote: > > > Hello all > > > > > > My intuition tells me this would be a bad idea, but before I try > > > anything with this, does anyone have any thoughts about how the > > > multi-usrp object would react in a situation where the process > > > has been forked? I know that the call to create a multi-usrp > > > object will fail if called in a second process, so I imagine it > > > won't like being in 2 separate address spaces. > > > > -- > > This was written on my cellular phone. whilst an impressive piece > > of engineering, this might not be the perfect device to write > > emails on - please excuse my brevity. > > > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
