On 2021-09-12 7:31 p.m., zhou wrote:
Thank you Marcus.
I tried as below:
my_stream_args.args["send_buff_size"] = std::to_string(500000);
my_stream_args.args["send_buff_size"] = std::to_string(5000000);
They give the same results. The 1MB limit still exists. I don't know
where this limit comes from.
Am I wrong in configuration?
I think I've already explained that the "send_buff_size" stream argument
controls the HOST SIDE BUFFER ONLY, since it
eventually just uses the standard Unix/Linux/BSD "socket" API call
setsockopt() to set the SO_SNDBUF option to the
value you provide.
The buffering ON THE USRP is a different matter, and as I've already
explained, this is likely fixed by the FPGA implementation.
You'd previously talked about the SD card on the N321, but there's NO
WAY that could be used for buffering--for one, it's
dedicated to the Linux filesystem on the device, and for a second,
it's VASTLY TOO SLOW. The DRAM on the N321 is dedicated
as far as I know, to the Linux CPU and if any of it is available for
the FPGA AT ALL, it's not going to be very much, and it's
likely FIXED TO A SPECIFIC VALUE by the implementation.
If you're seeing very-occasional LLL and U at very-high rates (and
believe me, multiple channels at 245Msps are *very high rates*),
then your issue is likely not strictly buffering related, but related
to something that Linux may be doing on your host "once in a while"
that changes the performance dynamics.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
