On Wed, Jan 24, 2024 at 2:43 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > > On 24/01/2024 13:00, jmalo...@umass.edu wrote: > > > > Hello, > > > > > > I currently have an application where I am burst receiving(about 80 > > micro per milli second) with the ettus X410 at the full sample rate > > across 4 channels. I am getting occasional issues where data is > > dropped (terminal messages show “D” error). I have been able to get > > DPDK to work but that does not seem to have resolved the issue. By my > > calculation, this comes out to a data rate of 5.12*10^9 Gbit/s > > > > The current host computer has an i9-13900KS, Nvme, 128 GB of RAM, and > > I am currently using a Mellanox 100 Gbit QSFP network card > > > > I would say in general, I am able to save just under 100% of all the > > data I request from the x410, however, for our application, it is very > > critical that we do not lose any data. If I run the default CG_400 > > image with benchmark rate(1 channel only), I do not get dropped data. > > The only significant difference between my custom host software and > > benchmark_rate.cpp is I save data to a .dat file(similar to > > rx_samples_to_file.cpp) . > > > > I have looked at the tuning notes here > > https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD. I have tried > > DPDK, core isolation/ disabling system interrupts, nice priority, > > multithreading/uhd::set_thread_priority, but none have seemed to > > resolve the issue. > > > > What I have noticed is that when I get a “D” error, it corresponds to > > recv() returning a number of samples less than samples per buffer, > > followed by a return value of 0. > > > > My current assumption is that the task of saving data to NVME is > > creating a critical path that cant be resolved with thread > > prioritization or multithreading. Or, maybe I am just not doing thread > > priority or multithreading correctly. Either way, it is strange to me > > that recv() can return a number of samples less than buffer outside of > > a stop signal or timeout signal. > > > > > > Any help/suggestion are appreciated, > > > > Joe > > > > > That suggests that packets are getting dropped somewhere in the network > stack -- possibly the network-card interface into > the kernel. > > You have done all the things here: > > https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks > > > Including increasing the number of ring buffers in the network card? >
Hi Joe, I noticed that you have 128GB RAM. If you turn this into a 120GB RAM drive, is this sufficient memory depth for your needs? If this is possible, there is a good chance it will solve your issue. Prior to DPDK, I tried to save to fast SSD and I always had problems at high rates (X310, etc, not X410 rates). I was always able to solve the problem by saving to a RAM drive. At one point I even wrote a separate utility to continually monitor and copy files from the RAM drive to the SSD so that the RAM drive never actually filled. Even when I toyed with DPDK (a long time ago), I had much improved behavior saving to SSD but still not as good as when I saved to RAM drive which always has given me performance that rivals benchmark_rate. Rob _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
