discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] USB throughput numbers for NetBSD (and Linux)


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] USB throughput numbers for NetBSD (and Linux)
Date: Sat, 22 Jul 2006 01:44:13 -0700
User-agent: Mutt/1.5.9i

On Sat, Jul 22, 2006 at 01:56:15AM -0400, Joanne M Mikkelson wrote:
> Hi,
> 
> We collected some data comparing the USB throughput we're getting now
> on NetBSD against the throughput on Linux.  For those who are
> interested in the current performance on NetBSD, I've included a
> summary.  The full set of measurements taken (along with the summary)
> is available at:
>     
> http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/radio_test/usb/test-results?view=co

Great report!

I'm not sure I followed the explanation for why on NetBSD the
unidirectional case isn't equal to the sum of the bidirectional case.
Could you try explaining again?  On second thought, is the problem
that there's only one request in the h/w endpoint queue for a given
endpoint and direction?  If so, I think you could get the completion
interrupt service time out of the critical path by ensuring that there
are always two requests queued in each direction, not just one.


I'd also be interested in seeing how the throughput holds up with
smaller transfer sizes and smaller total amount of buffer space.

For example, in gnuradio-examples/python/gmsk2/tunnel.py (ethernet
over GNU Radio using CSMA MAC) we're currently running with:

  1024 byte transfers, with a total of 16 blocks (16kB) in each direction.

If we can't enable real-time scheduling, then we run with

  4096 byte transfers, with a total of 16 blocks (64kB) in each direction.

As you can see, we've cut the total buffer allocated *way* down in
order to minimize the maximum round-trip latency as seen by a software
MAC.  These numbers were empirically chosen as "close to the smallest
values that works on Eric's laptops."  They can be overridden on the
command line, and  the defaults can be set in the user prefs file,
~/.gnuradio/config.conf:

    [fusb]
    rt_block_size = 1024
    rt_nblocks = 16
    block_size = 4096
    nblocks = 16

Currently only tunnel.py observes these settings.

FYI, test_usrp_standard_{tx,rx} support similar command line options:

  fprintf (stderr, "  [-B <fusb_block_size>] set fast usb block_size\n");
  fprintf (stderr, "  [-N <fusb_nblocks>] set fast usb nblocks\n");
  fprintf (stderr, "  [-R] set real time scheduling: SCHED_FIFO; pri = 
midpoint\n");


Thanks again for your efforts and the report!
Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]