"L" error for using file_sink blocks.

2024-12-12 Thread Yan, Bixing (UT-EEMCS)
Hi,

I am using USRP X440 to build a wireless communication prototype. The host PC 
is equipped with i9-14900K and I am trying to use two transmit channels and two 
receive channels of the USRP simultaneously. I feed two generated signal to two 
channels by the USRP_sink block, and then I download the received data  from 
the USRP_source  by file_sink blocks. The sample rate I use is 150 MHz for each 
channel.

However, I noticed that there are many "L" occurs when I run it. Even if I 
reduce the sample rate to 30 MHz, I can still see the problem. But if I use 
qt_gui_frequency_sink to visualize the received signal, it can hold up to 150 
MHz without any errors.

I would like to ask the reason for this. What cause the "L" errors? Is it about 
my ssd's writing speed is not high enough?

Thank you very much.


Re: "L" error for using file_sink blocks.

2024-12-12 Thread Marcus D. Leech

On 12/12/2024 12:16, Yan, Bixing (UT-EEMCS) wrote:

Hi,

I am using USRP X440 to build a wireless communication prototype. The 
host PC is equipped with i9-14900K and I am trying to use two transmit 
channels and two receive channels of the USRP simultaneously. I feed 
two generated signal to two channels by the USRP_sink block, and then 
I download the received data  from the USRP_source  by file_sink 
blocks. The sample rate I use is 150 MHz for each channel.


However, I noticed that there are many "L" occurs when I run it. Even 
if I reduce the sample rate to 30 MHz, I can still see the problem. 
But if I use qt_gui_frequency_sink to visualize the received signal, 
it can hold up to 150 MHz without any errors.


I would like to ask the reason for this. What cause the "L" errors? Is 
it about my ssd's writing speed is not high enough?


Thank you very much.
The Qt frequency sink uses a "stuttered" approach to calculating the 
FFT.  In order to service the desired frame-rate, it

  simply *drops* most sample frames.

Even at 30Msps X 2, that's 480Mbyte/second of I/O traffic to your disk 
subsystem.  That may well cause bus contention,
  and memory contention, and contention for the kernel's attention, 
depending on how your flow-graph is structured,

  what kind of disk drives you have, etc, etc.

You should probably post your flow-graph here so that folks (not just 
me) can form a more educated opinion...