Thanks Marcus. Yes, I am using 2xTx and 2xRx at 245Msps in N321.I understand
that if my host CPU is not fast enough, no matter how much buffer I have, it
won't help. Fortunately, my tests are actually working at most time, which
means that the CPU is fast enough for 245Msps. Maybe it is just marginally fast
enough, not super fast. I run the test for a few hours. Occasionally, there are
ULLL. So this is a stability issue. I think a bigger buffer will smooth the
ripples in host performance. Though separate CPUs and threads are used for Tx,
Rx, control and other processes, they share Linux, RAM and buses, so they are
not completely independent. There could be collision in resource access
occasionally. If that happens, Tx thread can be hung for a short while and
couldn't fill the buffer in time before the the device gets starved. Because
the current buffer is very small, its tolerance to such interrupt is very
limited. I think increasing the buffer size will make the system more reliable.
Thanks for mentioning the host-side buffer between the application layer and
the ethernet device drivers. How to check the existing setting, and how to
change it?
On Saturday, 11 September 2021, 15:42:09 BST, Marcus D. Leech
<patchvonbr...@gmail.com> wrote:
On 2021-09-11 1:56 a.m., zhou wrote:
Thank you Marcus. I originally thought that there might be two levels of
buffer, one in device and one in host, and the one in host was bigger and could
be configured by user, but after I checked the UHD library, I couldn't find the
host-side buffer. So, I agree with you that the host sends the packets to the
device immediately. There IS a host-side buffer. It exists in the OS kernel
between the application layer and the ethernet device drivers.
In *general* applications will write to I/O devices as fast as the kernel
will let them. This generally means that the
kernel must buffer traffic and then put the issuing thread to sleep when the
buffers are full. In the case of the network,
the NIC can only issue frames at a fixed rate (10Gbit or 1Gbit)--if the
application writes faster than that, then the
kernel buffer is there to help, and, as I said, will put the application
thread to sleep when the buffer is full.
In *addition* to all that, in the continuous-streaming case, the radio will
use (AFAIR) ethernet PAUSE frames to "pace"
the incoming data to allow smooth sending at exactly the desired sample
rate. This in turn will potentially trigger
the kernel buffer-management mechanisms, and potentially cause the sending
thread to go to sleep for a bit.
Now, when you specify the send_buff_size as a *stream* argument, that
ultimately, on Linux systems, causes the
UDP socket to be configured with setsockopt() using the SO_SNDBUF option to
tell the kernel what size of
buffer to use. It's a bit obscure in the code because the code supports
multiple types of I/O and network-stack
implementations.
I also did the same measurement on host using X310 USRP. The results are the
same as N321. Can I configure the send buffer size in device? especially in
N321. It has 1G DDR3 RAM and a huge SD card. I don't want a very big buffer;
10ms will be enough. The buffer size shall vary with sampling rate. I will
appreciate it very much if you could get clarification from the devs team.
Most of the DRAM on the N321 is for the Linux *CPU*, and is not available to
the FPGA implementation (or, if it is, there's
a fixed chunk and the FPGA would have to be recompiled). The dev team would
know best.
But I'll make this comment here. If the steady-state case that you're dealing
with is that your host CPU cannot "keep up"
with a demand for samples at 245Msps, then NO AMOUNT OF BUFFERING will help
you. Are you doing this on 4 channels
at once? That's an ungodly sample demand for even quite-well-appointed
computers, even if you're just streaming
pre-formed sample frames out of a RAM buffer. This isn't, at a high-level,
peculiar to USRPs or SDR or DSP. In ANY
producer-consumer architecture with real-time constraints, if the producer
cannot "keep up" with the consumer, then
no amount of pre-buffering will help for the continuous streaming case.
Even if the "producer" is able to keep up at
99.99% of the rate demand of the "consumer", buffers will eventually starve
and there'll be an underrun. Standard
computer-science stuff.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
