Number of blocks in a burst over USB

GNU Radio
1

I’ve tried finding this number throughout code and documentation, but
can’t seem
to hunt it down. When using usrp_standard_rx::make(), the last
parameter is
the number of blocks in a burst. What’s the magic number?

  • George
2

Eric B. wrote:

fusb_block_size = 1024
fusb_nblocks = 16

Okay, so the one of the reasons I moved d_urx->start() out of the
initialization code was
that it’s causing all of my machines to lockup within seconds. I’m
having a hard time
debugging this one as it is literally only seconds before things lock
up.

Without starting the RX side, the code runs to completion without
flinching
(test_usrp_inband). As soon as I start the RX side, lock up on all 3
machines I’ve tried
this on. Granted, they’re all Gentoo x86 machines. I’ve tried doubling
the USB block
size, still a lock up.

Any ideas?

  • George
3

On Tue, May 22, 2007 at 12:11:35AM -0400, George N. wrote:

I’ve tried finding this number throughout code and documentation, but can’t
seem to hunt it down. When using usrp_standard_rx::make(), the last
parameter is the number of blocks in a burst. What’s the magic number?

  • George

FYI, it’s in usrp_basic.h:

/*!

  • \param which_board Which USRP board on usb (not particularly
    useful; use 0)
  • \param fusb_block_size fast usb xfer block size. Must be a
    multiple of 512.
  •                     Use zero for a reasonable default.
  • \param fusb_nblocks number of fast usb URBs to allocate. Use
    zero for a reasonable default.
    */
    usrp_basic_rx (int which_board,
    int fusb_block_size=0,
    int fusb_nblocks=0,
    const std::string fpga_filename = “”,
    const std::string firmware_filename = “”
    ); // throws if trouble

It’s not the number of blocks in a burst. It’s the number of blocks
that are allocated for asynchronous tranfers.

I suggest starting with:

fusb_block_size = 4096
fusb_nblocks = 16

Though after everything is working and realtime scheduling is
enabled (for the usrp mblocks), we may want to switch to

fusb_block_size = 1024
fusb_nblocks = 16

Eric

4

Eric B. wrote:

What do you mean by “lock up”?
Mouse, keyboard, whole computer becomes unresponsive completely

Is it burning CPU cycles?
It does for about a second or two, and then becomes unresponsive to
everything on 2 of the
machines, only stuttered mouse movement on a third machine.

Have you tried running it under gdb?

Under gdb it gets to writing the vendor extension command to the USRP,
found in
write_cmd() of usrp_prims.cc … and right when it executes
usb_control_msg() in this
method is when the machine goes downhill and never returns.

Don’t enable real-time until you get this sorted out.

Definitely.

test_usrp_basic_rx in the usrp/host/apps/ directory works fine for me.
I do not see
anything different from the construction of the RX side other than the
xfer USB block size
and number of blocks to allocate.

  • George
5

On Wed, May 30, 2007 at 01:47:44PM -0400, George N. wrote:

test_usrp_basic_rx in the usrp/host/apps/ directory works fine for me. I do not see
anything different from the construction of the RX side other than the xfer USB block size
and number of blocks to allocate.

What values are you using for fusb_block_size and fusb_nblocks in the
constructor?
Have you checked the kernel logs? Is it oopsing?
How much ram is in your machine?
What kernel are you running?
You’re running Gentoo, right? What version?

Eric

6

On Tue, May 29, 2007 at 10:26:41PM -0400, George N. wrote:

Though after everything is working and realtime scheduling is
enabled (for the usrp mblocks), we may want to switch to

fusb_block_size = 1024
fusb_nblocks = 16

Okay, so the one of the reasons I moved d_urx->start() out of the initialization code was
that it’s causing all of my machines to lockup within seconds. I’m having a hard time
debugging this one as it is literally only seconds before things lock up.

What do you mean by “lock up”?
Is it burning CPU cycles?
Have you tried running it under gdb?
Don’t enable real-time until you get this sorted out.

Without starting the RX side, the code runs to completion without flinching
(test_usrp_inband). As soon as I start the RX side, lock up on all 3 machines I’ve tried
this on. Granted, they’re all Gentoo x86 machines. I’ve tried doubling the USB block
size, still a lock up.

Any ideas?

gdb is your friend. First job is to figure out what the code is doing
when you say that it’s hung. I suspect some kind of logic error in
your server code, but I haven’t looked at it.

Eric

7

Eric B. wrote:

What values are you using for fusb_block_size and fusb_nblocks in the constructor?
I’ve kept fusb_nblocks fixed at 16, and tried 4096 and 8192 for
fusb_block_size’s

Have you checked the kernel logs? Is it oopsing?

I have checked the logs, they are clean of anything that would provide a
hint. It is not
oopsing it seems. The last thing in the logs is always me plugging in
the USRP:
May 30 13:30:53 cyprus usb 1-7: new high speed USB device using ehci_hcd
and address 24
May 30 13:30:53 cyprus usb 1-7: configuration #1 chosen from 1 choice
May 30 13:40:05 cyprus cron[15097]: (root) CMD (test -x
/usr/sbin/run-crons &&
/usr/sbin/run-crons )
May 30 08:44:12 cyprus syslog-ng[4702]: syslog-ng version 1.6.11
starting

How much ram is in your machine?
1GB in all 3 machines with P4’s and hyperthreading enabled

What kernel are you running?
2.6.19 on two of the machines, 2.6.22-rc1 on the other

You’re running Gentoo, right? What version?

Gentoo 2007.0 profile

libusb is 0.1.12-r1

  • George