Hey Marcus Thanks for taking a look at this for me. Im a pretty competent computer engineer so I would be comfortable making modifications to UHD given your starting point. It may be a couple of weeks before I can look at this again, but I will try to look into this. I may need to pick your brain about it at sometime when I have a chance to look at the code. Working with so many USRPs has given me many troubles over the past few months.
On Thu, May 31, 2018, 04:28 Marcus Müller, <marcus.muel...@ettus.com> wrote: > 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
