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.muel...@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-users@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. > -- -Keith Kotyk
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
