Hey Nick Thanks for taking some time to help with this. Our CPU is an AMD Ryzen 7 1700X Eight-Core Processor. I tried UHD 3.9-LTS and I get some interesting results. I got much more lates on TX and nothing looked correct on the scope until I used a minimum of 50ms delay in the future. The UHD application also massively oversubscribed my cpu using this version. My program was still getting lates on RX after a few minutes of runtime. I also still get sequence errors too. Here is the line from the output of top.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5884 radar 20 0 1754.2m 69.3m 12.2m S 1002.3 0.432 2:25.56 test_rx_tx For comparison 3.10 does not give the same oversubscription. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31543 radar 20 0 524.9m 71.6m 13.9m S 51.495 0.446 0:11.02 test_rx_tx I also tried the new version of UHD, 3.11 and I get an error that it can't recognize the GPIO bank I've been using [INFO] [UHD] linux; GNU C++ version 4.8.5; Boost_105400; UHD_3.11.0.HEAD-0-g13c32cef [INFO] [USRP2] Opening a USRP2/N-Series device... [INFO] [USRP2] Current recv frame size: 1472 bytes [INFO] [USRP2] Current send frame size: 1472 bytes [INFO] [MULTI_USRP] 1) catch time transition at pps edge [INFO] [MULTI_USRP] 2) set times next pps (synchronously) Error: RuntimeError: The hardware has no gpio bank: RXA: I commented out those lines for now and tried running. With UHD 3.11, the application appears to be running, but I see nothing on USRPs to indicate things are working. The TX/RX leds don't light up nor do I see RF output on the scope. The UHD application is still throwing out sequence errors and a few underflow errors. On Thu, Mar 8, 2018 at 4:06 PM, Nate Temple <nate.tem...@ettus.com> wrote: > Hi Keith, > > Can you please give UHD 3.9.7 or the 3.9-LTS branch of a try with your > setup? > > What kind of CPU does your host have? What is the load profile while your > application is running? > > Regards, > Nate Temple > > On Thu, Mar 8, 2018 at 1:55 PM, Keith k via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hey all >> >> Just wondering if anyone had a chance to look at this for me. I'd >> appreciate it immensely! Thank you. >> >> On Fri, Mar 2, 2018 at 3:37 PM, Keith k <keithko...@gmail.com> wrote: >> >>> Hello all >>> >>> I'm working on a project to use 16 N200s in a multi USRP configuration >>> for a radar project. They are synchronized using 3 Octoclocks (one master >>> with a GPSDO, and two slaves that drive the 16 N200s). I've been getting >>> many errors that I was hoping someone could help with. I have attached a >>> sample program that mimics how the USRPs are used. The basic goal here is >>> to sample a determined number of samples while transmitting some spaced >>> pulses (a "pulse sequence") and then repeat. It would be beneficial to have >>> as little delay as possible in between loops. I've been running into some >>> problems however. >>> >>> BASIC INFO >>> We have 16 N200s + 1 spare >>> 3 Octoclocks (1 has gps and it drives the other two) >>> LFTX and LFRX daughterboards in each N200 >>> linux; GNU C++ version 4.8.5; Boost_105400; >>> UHD_003.010.002.000-0-gbd6e21dc >>> Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 >>> Devices are all connected via 3 daisy chained Netgear XS708E switches >>> Ideal sampling rates: 5-10MHz TX, 5-10MHz RX depending on >>> hardware/software limitations. >>> >>> One of the issues I sometimes get after several minutes of runtime (or >>> several thousand pulse sequences) is the overflow(O) with the out of >>> sequence flag set in the rx metadata. I also get sequence errors(S) on the >>> tx side too. It seems to happen more often and faster with higher sampling >>> rate. I've gathered from other mailing list posts that this is likely a >>> network configuration issue. Can someone recommend a known working computer >>> build and network configuration that can handle the amount of USRPs and >>> data we are attempting to use? >>> >>> Another major issue I eventually get during runtime is a slurry of >>> lates(L) on TX and then a LATE in the RX metadata. I've tried increasing >>> the time in the future that the TX/RX should start (from when the stream >>> commands are called) and I've tried to minimize the number of operations >>> happening between that calculation and when TX/RX start, but the lates >>> still eventually happen. I've tried to time profile what I can in my code >>> and it seems I should really only need about ~0.5ms of delay, but even at >>> 3-10ms of delay I have issues. I feel like 10ms of time should be more that >>> plenty of time for the host to issue stream commands. I don't seem to get >>> lates if I have test applications that individually test TX or RX, but when >>> I put them together using threads, I can't seem to find a way to eliminate >>> the lates. Any ideas on how I should set up what I'm trying to do here? >>> >>> Here is the compiler line to make the test program: >>> g++ -o test_rx_tx -std=c++11 -Wall test_rx_tx.cpp -lboost_system -luhd >>> >>> If I can explain anything in further detail please let me know. >>> >>> Thank you for your time. >>> >>> -- >>> -Keith Kotyk >>> >> >> >> >> -- >> -Keith Kotyk >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > -- -Keith Kotyk
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
