Hi, sorry for my long delay, I was on vacation and then playing
catch-up.
> 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
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:
I forgot to mention that I've put files for a change to the USRP fusb
driver to take advantage of the new ugen driver up at:
http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/radio_test/usb/fusb_netbsd/
for now. The files go in the corresponding directories in the usrp
source tree.
Thi
Many apologies for the delay in responding; somehow I missed this
message.
> Is there a consolidated patch file that would make it easier to apply against
> the current NetBSD source tree?
Attached is a patch file for the top level of the NetBSD source,
including all the files changed. config(8)
> There is a long outstanding bug in benchmark_usb that has it be
> unreliable. It's been a long time since I looked at it. The problem
> could be in the lfsr synchronization.
Yeah, I saw the comment in the file. What I find interesting about it
is that it's only failing for the slowest transfer
Hi all,
As was discussed here earlier (starting from
http://lists.gnu.org/archive/html/discuss-gnuradio/2006-05/msg00045.html
in the list archive), BBN has been working on improving the ugen(4)
driver for NetBSD.
We've now implemented the changes to the driver and it's handling
transfer rates of
