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