Fusb_nblock and fusb_block_size

GNU Radio
1

Hi all,

What do the parameters fusb_nblock and fusb_block_size exactly do in
how data is transmitted over the USB to the USRP? I assume that
fusb_nblock indicates how many blocks we have in each USB packet, and
fusb_block_size indicates how big one block is.

My question is, if there is less data available on the USRP (i.e. not
fusb_nblock*fusb_block_size), does it still get sent over the USRP to
the computer?

How is the smallest amount of data necessary in the USRP defined such
that a packet is sent over the USB to the computer? Is it
fusb_block_size?

Thank you very much,

Thomas

2

On Wed, Nov 29, 2006 at 01:46:14PM -0800, Thomas S. wrote:

Hi all,

What do the parameters fusb_nblock and fusb_block_size exactly do in
how data is transmitted over the USB to the USRP? I assume that
fusb_nblock indicates how many blocks we have in each USB packet, and
fusb_block_size indicates how big one block is.

fusb_block_size is the size in bytes of the maximum transfer that we
will ask the kernel to make to/from user-space. fusb_nblocks is the
maximum number of transfers (of maximum size fusb_block_size) that we
can have in flight at any given time.

Take a look at fusb_linux.{h,cc} for the details.

My question is, if there is less data available on the USRP (i.e. not
fusb_nblock*fusb_block_size), does it still get sent over the USRP to
the computer?

Yes. The USRP packages data into 512 byte USB packets and sends them
as soon as it can. That’s 128 complex samples (16-bit I & Q).

How is the smallest amount of data necessary in the USRP defined such
that a packet is sent over the USB to the computer? Is it
fusb_block_size?

It’s 512 bytes. It’s set in the FX2 firmware.

Eric

3

Hi Eric,

Thank you for the clarifications. I traced the code back to
usrp_basic.cc, but got lost there. I will have a look at
fusb_linux.{h/cc}.

Thomas

4

On Thu, Nov 30, 2006 at 01:29:16PM -0500, Greg T. wrote:

We’ll need to come up with a clean OS/HW independent way of dealing
with block sizes and controlling latency, along with enabling code to
end up at the lowest latency mode that works without hand tuning.

Yep :wink:

Eric

5

fusb_block_size is the size in bytes of the maximum transfer that we
will ask the kernel to make to/from user-space. fusb_nblocks is the
maximum number of transfers (of maximum size fusb_block_size) that we
can have in flight at any given time.

I think this is Linux-specific. The NetSBD USB implementation takes
the numbers and pushes them into the kernel where I think there is
similar treatment (total size of read-ahead buffer, and size of IO
request made to USB subsystem).

We’ll need to come up with a clean OS/HW independent way of dealing
with block sizes and controlling latency, along with enabling code to
end up at the lowest latency mode that works without hand tuning.