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
<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
<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
