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.
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.
On Friday, 10 September 2021, 23:18:39 BST, Marcus D. Leech
<patchvonbr...@gmail.com> wrote:
On 2021-09-10 6:05 p.m., zhou wrote:
Hi Marcus, thanks for your reply. No, I am not on MacOS. I am using Ubuntu.
How can I configure send buff size in Linux? I went through the uhd library but
could not see it had any limit on buffer size. So, very strange where the
buffer limit comes from.
How do I measure the buffer? I created a packet of 245760 bytes, and I set
metadata.has_time_spec = true, and configure metadata.time_spec to a future
time, then I sent the packets. Before metadata.time_spec, the sent packets
would be stored in the buffer. When send() was blocked, it meant the buffer was
full. I counted; after 4 packets, send got blocked. Only after time passed
metadata.time_spec, the packets in buffer were consumed, I could send another
packet. I'm not sure how much TX buffer space the N321 has in the FPGA, but it
sounds like that's what you're running into. I would expect it
to be very very much smaller than the amount of buffer available on the
host. I don't think UHD will "hold on" to packets on the host
side if it isn't quite time for them to be sent. It sends them to the
device, and if there isn't room on the device (because of
timed send), then it must necessarily ask the host to hold on to them.
It pretty-much HAS to work this way, since the host side has very little
control over latency, it has no way of really knowing
when it is safe to "release" timed TX packets to the actual hardware, so it
sends them to the hardware immediately.
One of the devs might be able to clarify, but that's my understanding.
On Friday, 10 September 2021, 19:53:29 BST, Marcus D. Leech
<patchvonbr...@gmail.com> wrote:
On 2021-09-10 2:39 p.m., zhou wrote:
Hi,
I am trying to increase the buffer size in tx.
According to https://files.ettus.com/manual/page_transport.html,
it seems that we can change the default send_buff_size by specifying value
in device arguments. I tried the following configuration:
uhd::usrp::multi_usrp::make('addr=192.168.12.2, second_addr=192.168.13.2,
mgmt_addr=192.168.10.16, master_clock_rate=245.76e6, type=n3xx,
send_buff_size=33554432')
But this didn't have any impact. I measured that the actual buffer is always
about ~1MB. How did you measure the buffer?
Then in UHD library, I find the following limit:
static const size_t MAX_BUFF_SIZE_ETH_MACOS = 0x100000; // 1Mib
if (link_params.send_buff_size > MAX_BUFF_SIZE_ETH_MACOS) {
link_params.send_buff_size = MAX_BUFF_SIZE_ETH_MACOS; }
Are you on MacOS? If not, that code isn't relevant. That code doesn't even
get compiled unless you're
on MacOS.
33554432 > 1048576 (1Mib), so this may be why the above config didn't work.
Then I tried the following configuration:
uhd::usrp::multi_usrp::make('addr=192.168.12.2,second_addr=192.168.13.2,mgmt_addr=192.168.10.16,master_clock_rate=245.76e6,type=n3xx,send_buff_size=524288')
This one didn't have any impact either. So, am I wrong in configuring
send_buff_size in this way? what is the correct way?
1M buffer size is too small for my application. I am using sampling rate
245.76MHz. This buffer can only save data up to 0.5ms. I want to allocate a
bigger buffer to achieve better reliability.
Thanks for any comment.
_______________________________________________
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
