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
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
<mailto: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
