I am not familiar with the USRP N321. But you could try putting the output file in /dev/shm or some other tmpfs filesystem to rule out some sort of disk write speed issue.
If you compiled UHD yourself, I have seen that using the appropriate g++ optimization flags help (eg -O3 or whatnot) . If you are able to connect both SFP+ ports on your USRP to your host system, you could have network traffic from the radio get split across both SFP+ ports by using the second_addr device argument (https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_usage). If your host system supports real-time scheduling, that can help with performance as well. uhd::set_thread_priority sets priorities to real-time by default, but I'm not too familiar with the examples and how to have them do that for you. Looking at your program output, you also need to change the master clock rate of your radio to do 250MSps (it was unable to set the sampling rate to 250MSps), though the specs for the N321 say it only has access to 200MHz of bandwidth per receive channel. If you're just trying to see if you can do 10Gb from your one ethernet adapter, you can maybe do 2 ~150MSps collects at once, one from each channel. You can use the benchmark_rate UHD example to do that (https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio#Benchmarking_your_system) (https://github.com/EttusResearch/uhd/blob/master/host/examples/benchmark_rate.cpp); set rx_channels to 0,1. Use the master_clock_rate UHD device arg to set the master clock rate appropriately if it fails setting the sampling rate eg --args="addr=192.168.10.2,master_clock_rate=100e6" Good luck Thank you, Andrew Fountain Black River Systems Co., Inc. 162 Genesee Street Utica, NY 13502 ________________________________ From: DOR-ISAAC SHABTAY <d...@rafael.co.il> Sent: Monday, March 25, 2024 10:05 AM To: usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> Cc: DOR-ISAAC SHABTAY <d...@rafael.co.il> Subject: [EXTERNAL][USRP-users] USRP N321 - Dropped packets You don't often get email from d...@rafael.co.il. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> *** CAUTION: This email originated from outside of Black River Systems Co. Do not click links or open attachments or respond unless you recognize the sender and know the content is safe. *** Hi, I'm using usrp N321 to sample data at IQ rate of 250 MSPS. I have dropped packets. ________________________________________________________________________ sync; sudo nice -n -20 /usr/lib/uhd/examples/rx_samples_to_file --freq 1e9 --rate 250e6 --file /media/data/data10.dat --args "addr=192.168.10.2" Creating the usrp device with: addr=192.168.10.2... [INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; UHD_4.6.0.0-0ubuntu1~jammy1 [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n320,serial=32AC3CE,name=ni-n3xx-32AC3CE,fpga=XG,claimed=False,addr=192.168.10.2 [INFO] [MPM.PeriphManager] init() called with device args `fpga=XG,mgmt_addr=192.168.10.2,name=ni-n3xx-32AC3CE,product=n320,clock_source=internal,time_source=internal'. Using Device: Single USRP: Device: N300-Series Device Mboard 0: n320 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Rhodium RX Channel: 1 RX DSP: 1 RX Dboard: B RX Subdev: Rhodium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Rhodium TX Channel: 1 TX DSP: 1 TX Dboard: B TX Subdev: Rhodium Setting RX Rate: 250.000000 Msps... Actual RX Rate: 245.760000 Msps... Setting RX Freq: 1000.000000 MHz... Setting RX LO Offset: 0.000000 MHz... [WARNING] [MULTI_USRP] Could not set RX rate to 250.000 MHz. Actual rate is 245.760 MHz [WARNING] [MULTI_USRP] Could not set RX rate to 250.000 MHz. Actual rate is 245.760 MHz Actual RX Freq: 1000.000000 MHz... [INFO] [MPM.Rhodium-0] init() called with args `fpga=XG,mgmt_addr=192.168.10.2,name=ni-n3xx-32AC3CE,product=n320,clock_source=internal,time_source=internal' [INFO] [MPM.Rhodium-1] init() called with args `fpga=XG,mgmt_addr=192.168.10.2,name=ni-n3xx-32AC3CE,product=n320,clock_source=internal,time_source=internal' Locking LO on channel 0 Waiting for "lo_locked": ++++++++++ locked. Press Ctrl + C to stop streaming... Disk write test indicates that an overflow is likely to occur. Your write medium must sustain a rate of 983.040MB/s, but write test returned write speed of 346.000MB/s. The disk write rate is also affected by system load and OS/disk caching capacity. OGot an overflow indication. Please consider the following: Your write medium must sustain a rate of 983.040MB/s. Dropped samples will not be written to the file. Please modify this example for your purposes. This message will not appear again. ODDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDODDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDODDDDDDDDDDDDDDDDOODDDDDDDDDDDDDDDDDDDDDDDDODDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDO^C Done! _________________________________________________________________________ Host PC: Intel NUC - NUC11TNHi7 Ubuntu 22.04 Linux kernel version - 6.5.0 we have separate HDs for OS (SATA 2.5'') and storage (fast SSD NVME) we are using QNA-T310G1S as adapter SFP <--> Thunderbolt. we tried the following (from https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks and https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD): * CPU Governor (CPU governor to performance for all cores) * Adjust Network Buffers * Adjust Ethernet MTU (the MTU is 9000) * Increasing Ring Buffers * Increasing num_recv_frames (num_recv_frames=512) * Extra nice Priority (sudo nice -n -20) Can we use dpdk with QNAP? what is the 'dpdk_mac' than? Thanks, David Stanley This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:law...@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof..
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
