[Discuss-gnuradio] NetBSD and sysv shm
I fixed a memory leak in an error case in the sysv shm vmcircbuf tests. Now the test leaves no shm turds in either success or error cases. I found that I had to set the number of shm segment names and segments per process to what seem unreasonably high values. This is documented in http://gnuradio.utah.edu/trac/wiki/NetBSDInstall and I'll raise it with NetBSD folks as it seems there is something wrong. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD and sysv shm
I looked into this more, and conclude that there is no evidence for bugs in NetBSD shm support, just perhaps resource defaults that aren't big enough. The reason so many attachments are needed is that 64 objects are created, and each has 4 shmat calls. This seems excessive, but I don't know if the test is intended to consume that many resources. Eric and I have recently beat on the few known NetBSD nits; now make check passes on NetBSD 4.0_BETA2 with up-to-date packages from pkgsrc (including jack, port-audio, SDL, py-ephem so most components are built). -- Greg Troxel [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD and sysv shm
On Wed, Jan 31, 2007 at 03:01:51PM -0500, Greg Troxel wrote: I looked into this more, and conclude that there is no evidence for bugs in NetBSD shm support, just perhaps resource defaults that aren't big enough. The reason so many attachments are needed is that 64 objects are created, and each has 4 shmat calls. This seems excessive, but I don't know if the test is intended to consume that many resources. 64 is possibly a little high, but the idea was to have the failure at make check time rather than downstream at runtime. At runtime there is a buffer object allocated for each output of each block. There are 4 attaches to create each buffer. Two of them are for guard regions on either side of the buffer. Those regions are setup READ_ONLY, and are to trap write accesses off the beginning or end of the bufer. If munmap is available, we could modify the code to create holes that had no access. The other two are the mappings that implement the two continguous copies of the circular buffer. Eric and I have recently beat on the few known NetBSD nits; now make check passes on NetBSD 4.0_BETA2 with up-to-date packages from pkgsrc (including jack, port-audio, SDL, py-ephem so most components are built). Greg Troxel [EMAIL PROTECTED] Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
Thanks, i'll try to look into this. -- Greg Troxel [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
On Sat, Dec 02, 2006 at 03:02:54PM -0800, Jordan Hayes wrote: usb_control_msg failed: error sending control message: Input/output error I haven't tracked this down, but I'd be interested in fixing it. I suspect it's either something missing in NetBSD or some OS-dependent code that isn't properly abstracted. I think it might be coming from libusb, but I really don't know - the error message is a bit lame. If you can figure out the call chain that results in the error (perhaps with ktrace on the simplest program that provokes it), that would be helpful. Ok, I put a few printfs in there. You're right: the error message comes from libusb, but the usb_control_msg part comes from usrp/host/lib/usrp_prims.cc in the function write_cmd() and the args are rType=8 val=87 index=0 len=1 and so that's VRQ_I2C_WRITE so i'm gonna guess that this is the usrp_eeprom_write() call that includes this code: I doubt it's coming from usrp_eeprom_write() since almost nobody calls that. Depending on the daughterboard, it could be code that's setting up the daughterboard. To find out for sure, set a breakpoint with gdb and get a backtrace. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
Ok, I put a few printfs in there. You're right: the error message comes from libusb, but the usb_control_msg part comes from usrp/host/lib/usrp_prims.cc in the function write_cmd() and the args are rType=8 val=87 index=0 len=1 and so that's VRQ_I2C_WRITE so i'm gonna guess that this is the usrp_eeprom_write() call that includes this code: I doubt it's coming from usrp_eeprom_write() since almost nobody calls that. Depending on the daughterboard, it could be code that's setting up the daughterboard. To find out for sure, set a breakpoint with gdb and get a backtrace. #0 write_cmd (udh=value optimized out, request=8, value=87, index=0, bytes=0xbfbfd3cb , len=1) at usrp_prims.cc:450 #1 0xbb19dd07 in usrp_i2c_write (udh=0x84e6e00, i2c_addr=87, buf=0xbfbfd3cb, len=1) at usrp_prims.cc:960 #2 0xbb19dd44 in usrp_eeprom_read (udh=0x84e6e00, i2c_addr=87, eeprom_offset=0, buf=0xbfbfd424, len=32) at usrp_prims.cc:1124 #3 0xbb19dddc in read_dboard_eeprom (udh=0x84e6e00, slot_id=value optimized out, buf=0xbfbfd424 \n) at usrp_prims.cc:1293 #4 0xbb19de49 in usrp_read_dboard_eeprom (udh=0x84e6e00, slot_id=3, eeprom=0xbfbfd47c) at usrp_prims.cc:1317 #5 0xbb19ba9e in usrp_basic_rx::probe_rx_slots (this=0x8698000, verbose=false) at usrp_basic.cc:721 #6 0xbb19c5ca in usrp_basic_rx (this=0x8698000, which_board=0, fusb_block_size=4096, fusb_nblocks=16, [EMAIL PROTECTED], [EMAIL PROTECTED]) at usrp_basic.cc:467 #7 0xbb1a1784 in usrp_standard_rx (this=0x8698000, which_board=0, decim_rate=64, nchan=1, mux=839922192, mode=0, fusb_block_size=4096, fusb_nblocks=16, [EMAIL PROTECTED], [EMAIL PROTECTED]) at usrp_standard.cc:158 #8 0xbb1a1ea7 in usrp_standard_rx::make (which_board=0, decim_rate=64, nchan=1, mux=839922192, mode=0, fusb_block_size=4096, fusb_nblocks=16, [EMAIL PROTECTED], [EMAIL PROTECTED]) at usrp_standard.cc:228 #9 0xbb15c584 in usrp1_source_base (this=0x804c740, [EMAIL PROTECTED], [EMAIL PROTECTED], which_board=0, decim_rate=64, nchan=1, mux=839922192, mode=0, fusb_block_size=4096, fusb_nblocks=16, [EMAIL PROTECTED], [EMAIL PROTECTED]) at usrp1_source_base.cc:56 #10 0xbb15cba9 in usrp1_source_c (this=0x804c740, which_board=0, decim_rate=64, nchan=1, mux=839922192, mode=0, fusb_block_size=4096, fusb_nblocks=16, [EMAIL PROTECTED], [EMAIL PROTECTED]) at usrp1_source_c.cc:73 #11 0xbb15d125 in usrp1_make_source_c (which_board=0, decim_rate=64, nchan=1, mux=839922192, mode=0, fusb_block_size=4096, fusb_nblocks=16, [EMAIL PROTECTED], [EMAIL PROTECTED]) at usrp1_source_c.cc:55___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
On Sunday 03 December 2006 07:42, Jordan Hayes wrote: Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the following message: usb_control_msg failed: error sending control message: Input/output error It doesn't seem to stop the program from running, but it's a little annoying. Anyone know what it means? This was raised previously in following thread http://www.nabble.com/USRP-on-NetBSD-p1964955.html No fix has surfaced since then. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the following message: usb_control_msg failed: error sending control message: Input/output error I haven't tracked this down, but I'd be interested in fixing it. I suspect it's either something missing in NetBSD or some OS-dependent code that isn't properly abstracted. I think it might be coming from libusb, but I really don't know - the error message is a bit lame. If you can figure out the call chain that results in the error (perhaps with ktrace on the simplest program that provokes it), that would be helpful. BTW if you run -current instead of 3.1, the USRP should do 16 MB/s each way instead of 4 MB/s that you probably get on 3.1. The improvements were committed sometime this summer. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
usb_control_msg failed: error sending control message: Input/output
error
I haven't tracked this down, but I'd be interested in fixing it. I
suspect it's either something missing in NetBSD or some OS-dependent
code that isn't properly abstracted. I think it might be coming from
libusb, but I really don't know - the error message is a bit lame. If
you can figure out the call chain that results in the error (perhaps
with ktrace on the simplest program that provokes it), that would be
helpful.
Ok, I put a few printfs in there. You're right: the error message comes
from libusb, but the usb_control_msg part comes from
usrp/host/lib/usrp_prims.cc in the function write_cmd() and the args are
rType=8 val=87 index=0 len=1 and so that's VRQ_I2C_WRITE so i'm gonna
guess that this is the usrp_eeprom_write() call that includes this code:
// The simplest thing that could possibly work:
// all writes are single byte writes.
//
// We could speed this up using the page write feature,
// but we write so infrequently, why bother...
while (len-- 0){
cmd[0] = eeprom_offset++;
cmd[1] = *p++;
bool r = usrp_i2c_write (udh, i2c_addr, cmd, sizeof (cmd));
mdelay (10);// delay 10ms worst case write time
if (!r)
return false;
}
That's a single byte write ...
Now: why this is failing and the rest of everything still works, that's
up to someone else ...
/jordan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD Package Collection for GNU Radio 3.0.2
G'day, For those running NetBSD, I've updated the NetBSD Packages Collection to accommodate the release of GNU Radio 3.0.2. GNU Radio is split into modular packages, see below, giving users maximum control over the installation process. Those that are lazy may issue make install inside the meta-pkgs/gnuradio directory which will build and install all GNU Radio modules including any missing dependencies. Meta-Package: = gnuradio-3.0.2 New Package: gnuradio-core-docs-3.0.2 gnuradio-audio-jack-3.0.2 gnuradio-audio-portaudio-3.0.2 gnuradio-video-sdl-3.0.2 gnuradio-trellis-3.0.2 gnuradio-radio-astronomy-3.0.2 usrp-docs-3.0.2 Updated Packages: gnuradio-core-3.0.2 gnuradio-audio-oss-3.0.2 gnuradio-gsm-3.0.2 gnuradio-usrp-3.0.2 gnuradio-wxgui-3.0.2 gnuradio-examples-3.0.2 gnuradio-howto-3.0.2 usrp-3.0.2 Visit http://www.netbsd.org/Documentation/software/packages.html for more information about the NetBSD Packages Collection. Note: NetBSD Packages Collection supports many other platforms including Linux, FreeBSD, Solaris, OS/X and many more - see below http://www.netbsd.org/Documentation/software/packages.html#platforms Enjoy, 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD build status
I think my earlier stabs complaints were just warnings. I had a bad install of sdcc; the sdcc Makefiles use 'cp -r' and not 'cp -rf' or install and a stale empty directory prevented the install of some needed files. Now, I think my only real build problem is in the ECC code: gr-error-correcting-codes/src/lib $ gmake gmake all-recursive gmake[1]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib' Making all in libecc gmake[2]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib/libecc' Making all in mld gmake[3]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib/libecc/mld' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib/libecc/mld' Making all in . gmake[3]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib/libecc' gmake[3]: Nothing to be done for `all-am'. gmake[3]: Leaving directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib/libecc' Making all in tests gmake[3]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib/libecc/tests' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib/libecc/tests' gmake[2]: Leaving directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib/libecc' gmake[2]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/gr-error-correcting-codes/src/lib' if /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../gnuradio-core/src/lib/runtime -I../../../gnuradio-core/src/lib/general -I../../../gnuradio-core/src/lib/general -I../../../gnuradio-core/src/lib/filter -I../../../gnuradio-core/src/lib/filter -I../../../gnuradio-core/src/lib/reed-solomon -I../../../gnuradio-core/src/lib/io -I../../../gnuradio-core/src/lib/g72x -I../../../gnuradio-core/src/lib/omnithread -I../../../gnuradio-core/src/lib/swig -I../../../gnuradio-core/src/lib/swig -I/usr/pkg/include-I/usr/pkg/include/python2.3 -I/usr/pkg/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT ecc.lo -MD -MP -MF .deps/ecc.Tpo -c -o ecc.lo ecc.cc; \ then mv -f .deps/ecc.Tpo .deps/ecc.Plo; else rm -f .deps/ecc.Tpo; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../gnuradio-core/src/lib/runtime -I../../../gnuradio-core/src/lib/general -I../../../gnuradio-core/src/lib/general -I../../../gnuradio-core/src/lib/filter -I../../../gnuradio-core/src/lib/filter -I../../../gnuradio-core/src/lib/reed-solomon -I../../../gnuradio-core/src/lib/io -I../../../gnuradio-core/src/lib/g72x -I../../../gnuradio-core/src/lib/omnithread -I../../../gnuradio-core/src/lib/swig -I../../../gnuradio-core/src/lib/swig -I/usr/pkg/include -I/usr/pkg/include/python2.3 -I/usr/pkg/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT ecc.lo -MD -MP -MF .deps/ecc.Tpo -c ecc.cc -fPIC -DPIC -o .libs/ecc.o ecc.cc: In function 'int SWIG_AsVal_bool(PyObject*, bool*)': ecc.cc:4465: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc:4468: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc: In function 'PyObject* _wrap_x_vector_ecc_streams_encode_convolutional_sptr_erase__SWIG_0(PyObject*, PyObject*)': ecc.cc:5936: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc: In function 'PyObject* _wrap_x_vector_ecc_streams_encode_convolutional_sptr_erase__SWIG_1(PyObject*, PyObject*)': ecc.cc:5978: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc:5989: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc: In function 'PyObject* _wrap_x_vector_ecc_streams_encode_convolutional_sptr_erase(PyObject*, PyObject*)': ecc.cc:6025: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc:6038: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc:6042: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc: In function 'PyObject* _wrap_x_vector_ecc_streams_encode_convolutional_sptr_insert__SWIG_0(PyObject*, PyObject*)': ecc.cc:6381: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc: In function 'PyObject* _wrap_x_vector_ecc_streams_encode_convolutional_sptr_insert__SWIG_1(PyObject*, PyObject*)': ecc.cc:6434: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc: In function 'PyObject* _wrap_x_vector_ecc_streams_encode_convolutional_sptr_insert(PyObject*, PyObject*)': ecc.cc:6482: warning: dereferencing type-punned pointer will break strict-aliasing rules ecc.cc:6499: warning: dereferencing type-punned pointer will break strict-aliasing
Re: [Discuss-gnuradio] NetBSD build status
On Fri, August 11, 2006 10:32, Greg Troxel wrote: Now, I think my only real build problem is in the ECC code: We've had enough bug reports on this particular piece of code that when I get back from my trip I will disable this component in the trunk. It appears that this is a compiler version issue; I believe the code author is relying on an older version of gcc (3.x) which has changed behavior in 4.x. In any case you can do this your self with a # in front of the GR_ERROR_CORRECTING_CODES line in configure.ac. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD build status
On Aug 11, 2006, at 2:02 PM, Johnathan Corgan wrote: On Fri, August 11, 2006 10:32, Greg Troxel wrote: Now, I think my only real build problem is in the ECC code: We've had enough bug reports on this particular piece of code that when I get back from my trip I will disable this component in the trunk. A wise choice IMHO. Hope you're able to enjoy your trip ;-) It appears that this is a compiler version issue; I believe the code author is relying on an older version of gcc (3.x) which has changed behavior in 4.x. I'm using Apple's version of GCC 4.0.1 (XCode 2.3). I will try XCode 2.4, but I doubt it will help from the compiler perspective. It's also possible that the (now) stale code in gr-ecc is causing the issue. W/o commit access (or, rather, that I don't know that I have commit access if I do), how should I make mods to that code-base? - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD USRP USB changes committed to master repository
On Monday I committed the changes to ugen(4) that Joanne previously described on the list to the master NetBSD repository. The option is enabled in GENERIC and GENERIC_LAPTOP on i386 and GENERIC on amd64, and is described in the ugen(4) man page. Updating to the latest -current should be sufficient to get these changes. Berndt Josef Wulf reports that they work for him when using the fusb code, available at http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/radio_test/usb/ I am interested in reports of how well this works on both i386 and amd64. It's pretty clear that getting pipelining closer to the hardware is needed - this is being pushed upstream since it works and gets ~80% of the likely speed gain. From: Greg Troxel [EMAIL PROTECTED] Subject: CVS commit: src To: [EMAIL PROTECTED] Date: Mon, 24 Jul 2006 14:24:50 + (UTC) Reply-To: [EMAIL PROTECTED] Module Name:src Committed By: gdt Date: Mon Jul 24 14:24:50 UTC 2006 Modified Files: src/share/man/man4: ugen.4 src/sys/arch/i386/conf: GENERIC GENERIC_LAPTOP src/sys/dev/usb: files.usb ugen.c usb.h Log Message: Add UGEN_BULK_RA_WB, which allows users of ugen(4) to request read ahead and write behind, improving performance for the Universal Software Radio Peripheral (USRP) used with GNU Radio. Enable UGEN_BULK_RA_WB in GENERIC and GENERIC_LAPTOP; behavior is unchanged unless the new ioctl is called. This code was written by Joanne Mikkelson under funding from DARPA's ACERT program. ok'd by christos@, tested by Berndt Josef Wulf To generate a diff of this commit: cvs rdiff -r1.21 -r1.22 src/share/man/man4/ugen.4 cvs rdiff -r1.762 -r1.763 src/sys/arch/i386/conf/GENERIC cvs rdiff -r1.190 -r1.191 src/sys/arch/i386/conf/GENERIC_LAPTOP cvs rdiff -r1.67 -r1.68 src/sys/dev/usb/files.usb cvs rdiff -r1.83 -r1.84 src/sys/dev/usb/ugen.c cvs rdiff -r1.73 -r1.74 src/sys/dev/usb/usb.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- Greg Troxel [EMAIL PROTECTED] pgp96yZCCXMKt.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USRP USB changes committed to master repository
On Wednesday 26 July 2006 22:22, Greg Troxel wrote:
On Monday I committed the changes to ugen(4) that Joanne previously
described on the list to the master NetBSD repository. The option is
enabled in GENERIC and GENERIC_LAPTOP on i386 and GENERIC on amd64,
and is described in the ugen(4) man page.
Updating to the latest -current should be sufficient to get these
changes. Berndt Josef Wulf reports that they work for him when using
the fusb code, available at
http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/radio_test/usb/
I am interested in reports of how well this works on both i386 and
amd64.
It's pretty clear that getting pipelining closer to the hardware is
needed - this is being pushed upstream since it works and gets ~80% of
the likely speed gain.
[...]
G'day,
for those interested here are a few results from the tests conducted on a Dell
Inspiron 9400 Centrino Duo @ 2GHz/1GB running NetBSD-3.99.21:
barossa: {29} ./test_usrp_standard_rx
xfered 1.34e+08 bytes in 4.2 seconds. 3.197e+07 bytes/sec. cpu time =
0.04173
noverruns = 41
barossa: {30} ./test_usrp_standard_tx
...
usb_control_msg failed: error sending control message: Input/output error
xfered 1.34e+08 bytes in 4.64 seconds. 2.894e+07 bytes/sec. cpu time = 0.491
41 underruns
barossa: {33} ./benchmark_usb.py
Testing 2MB/sec... usb_control_msg failed: error sending control message:
Input/output error
uUusb_throughput = 2M
ntotal= 100
nright= 947559
runlength = 0
delta = 100
FAILED
Testing 4MB/sec... usb_control_msg failed: error sending control message:
Input/output error
uUusb_throughput = 4M
ntotal= 200
nright= 1997896
runlength = 1997896
delta = 2104
OK
Testing 8MB/sec... usb_control_msg failed: error sending control message:
Input/output error
usb_throughput = 8M
ntotal= 400
nright= 3999286
runlength = 3999286
delta = 714
OK
Testing 16MB/sec... usb_control_msg failed: error sending control message:
Input/output error
usb_throughput = 16M
ntotal= 800
nright= 7997737
runlength = 7997737
delta = 2263
OK
Testing 32MB/sec... usb_control_msg failed: error sending control message:
Input/output error
usb_throughput = 32M
ntotal= 1600
nright= 15999303
runlength = 15999303
delta = 697
OK
Max USB/USRP throughput = 32MB/sec
Interestingly, the 2MB/sec test fails although the faster speeds are ok.
cheerio Berndt
pgpUl304aTUCV.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USRP USB changes committed to master repository
barossa: {29} ./test_usrp_standard_rx
xfered 1.34e+08 bytes in 4.2 seconds. 3.197e+07 bytes/sec. cpu time =
0.04173
noverruns = 41
barossa: {30} ./test_usrp_standard_tx
...
usb_control_msg failed: error sending control message: Input/output error
xfered 1.34e+08 bytes in 4.64 seconds. 2.894e+07 bytes/sec. cpu time = 0.491
41 underruns
So this doesn't work. Could you try with decimation 10 (or 12, until
you get only a few underruns)?
Interestingly, the 2MB/sec test fails although the faster speeds are ok.
We've noticed that too. Note that the 32 MB/s speed is really 16 MB/s
in each direction.
It would be cool if benchmark_usrp.py tried decimation 14, 12, and 10
also, rather than stopping at 16 (and interpolation values with those
rates).
--
Greg Troxel [EMAIL PROTECTED]
pgpTx5LBjnVgP.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USRP USB changes committed to master repository
On Wednesday 26 July 2006 23:19, Greg Troxel wrote:
barossa: {29} ./test_usrp_standard_rx
xfered 1.34e+08 bytes in 4.2 seconds. 3.197e+07 bytes/sec. cpu time =
0.04173
noverruns = 41
barossa: {30} ./test_usrp_standard_tx
...
usb_control_msg failed: error sending control message: Input/output error
xfered 1.34e+08 bytes in 4.64 seconds. 2.894e+07 bytes/sec. cpu time =
0.491 41 underruns
So this doesn't work. Could you try with decimation 10 (or 12, until
you get only a few underruns)?
Here are the values that stop producing overruns:
barossa: {101} ./test_usrp_standard_rx -D 10
xfered 1.34e+08 bytes in 5.24 seconds. 2.56e+07 bytes/sec. cpu time = 0.0399
noverruns = 0
barossa: {106} ./test_usrp_standard_tx -I 20
usb_control_msg failed: error sending control message: Input/output error
xfered 1.34e+08 bytes in 5.28 seconds. 2.542e+07 bytes/sec. cpu time = 0.492
0 underruns
cheerio Berndt
pgphobctz99PA.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USRP USB changes committed to master repository
On Wed, Jul 26, 2006 at 09:49:10AM -0400, Greg Troxel wrote: Interestingly, the 2MB/sec test fails although the faster speeds are ok. We've noticed that too. Note that the 32 MB/s speed is really 16 MB/s in each direction. It would be cool if benchmark_usrp.py tried decimation 14, 12, and 10 also, rather than stopping at 16 (and interpolation values with those rates). It would be even better if it gave reliable answers ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USB progress
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) will automatically create
the enigmatic opt_ugen_bulk_ra_wb.h file. To actually include the
changes in your kernel compile (they are not enabled by default), add
options UGEN_BULK_RA_WB to your kernel config.
Joanne
Index: share/man/man4/ugen.4
===
RCS file: /cvs/netbsd/netbsd/src/share/man/man4/ugen.4,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- share/man/man4/ugen.4 23 Nov 2005 08:56:08 - 1.1.1.1
+++ share/man/man4/ugen.4 26 Jun 2006 21:02:02 - 1.2
@@ -77,14 +77,14 @@
If an endpoint address is used both for input and output the device
can be opened for both read or write.
.Pp
-To find out what endpoints that exist there are a series of
+To find out what endpoints exist there are a series of
.Xr ioctl 2
-operation on the control endpoint that returns the USB descriptors
+operations on the control endpoint that return the USB descriptors
of the device, configurations, interfaces, and endpoints.
.Pp
The control transfer mode can only happen on the control endpoint
-which is always endpoint 0. The control endpoint accepts request
-and may respond with an answer to such request. Control request
+which is always endpoint 0. The control endpoint accepts requests
+and may respond with an answer to such requests. Control requests
are issued by
.Xr ioctl 2
calls.
@@ -108,7 +108,15 @@
and
.Xr write 2
should be used.
-All IO operations on a bulk endpoint are unbuffered.
+All IO operations on a bulk endpoint are normally unbuffered.
+Buffering can be enabled using a
+.Dv USB_SET_BULK_RA
+or
+.Dv USB_SET_BULK_WB
+.Xr ioctl 2
+call, to enable read-ahead and write-behind respectively. When
+read-ahead or write-behind are enabled, the file descriptor may
+be set to use non-blocking IO.
.Pp
The interrupt transfer mode can be in or out depending on the
endpoint.
@@ -272,6 +280,57 @@
issue any USB transactions.
.El
.Pp
+Bulk endpoints handle the following
+.Xr ioctl 2
+calls:
+.Pp
+.Bl -tag -width indent -compact
+.It Dv USB_SET_BULK_RA (int)
+Enable or disable bulk read-ahead. When enabled, the driver will
+begin to read data from the device into a buffer. The
+.Xr read 2
+call will read data from this buffer, blocking if necessary until
+there is enough data to read the length of data requested. The
+buffer size and the read request length can be set by the
+.Dv USB_SET_BULK_RA_OPT
+.Xr ioctl 2
+call.
+.It Dv USB_SET_BULK_WB (int)
+Enable or disable bulk write-behind. When enabled, the driver will
+buffer data from the
+.Xr write 2
+call before writing it to the device.
+.Xr write 2
+will block if there is not enough room in the buffer for all
+the data. The buffer size and the write request length can be set
+by the
+.Dv USB_SET_BULK_WB_OPT
+.Xr ioctl 2
+call.
+.It Dv USB_SET_BULK_RA_OPT (struct usb_bulk_ra_wb_opt)
+Set the size of the buffer and the length of the read requests used by
+the driver when bulk read-ahead is enabled. The changes do not take
+effect until the next time bulk read-ahead is enabled. Read requests
+are made for the length specified, and the host controller driver
+(i.e.,
+.Xr ehci 4 ,
+.Xr ohci 4 , and
+.Xr uhci 4 ) will perform as many bus transfers as required. If
+transfers from the device should be smaller than the maximum length,
+.Dv ra_wb_request_size
+must be set to the required length.
+.Bd -literal
+struct usb_bulk_ra_wb_opt {
+ int ra_wb_buffer_size;
+ int ra_wb_request_size;
+};
+.Ed
+.It Dv USB_SET_BULK_WB_OPT (struct usb_bulk_ra_wb_opt)
+Set the size of the buffer and the length of the write requests used
+by the driver when bulk write-behind is enabled. The changes do not
+take effect until the next time bulk write-behind is enabled.
+.El
+.Pp
Note that there are two different ways of addressing configurations,
interfaces,
alternatives, and endpoints: by index or by number.
The index is the ordinal number (starting from 0) of the descriptor
Index: sys/dev/usb/files.usb
===
RCS file: /cvs/netbsd/netbsd/src/sys/dev/usb/files.usb,v
retrieving revision 1.1.1.2
retrieving revision 1.3
diff -u -r1.1.1.2 -r1.3
--- sys/dev/usb/files.usb 19 Jun 2006 15:44:45 - 1.1.1.2
+++ sys/dev/usb/files.usb 26 Jun 2006 20:17:32 - 1.3
@@ -48,6 +48,7 @@
# Generic devices
+defflag UGEN_BULK_RA_WB
device ugen
attach ugen at uhub
file dev/usb/ugen.c ugenneeds-flag
Index: sys/dev/usb/ugen.c
===
RCS file:
Re: [Discuss-gnuradio] NetBSD USB progress
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. This fusb_netbsd code was developed for testing the driver work, and won't work terribly well with the unmodified ugen. But hopefully it'll help out anyone trying out the ugen changes at this point. Joanne ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USB progress
This is much improved over ~4 MB/s but the next step is to work on optimizing what's needed to reach 32 MB/s reading or writing. If you're interested, the current driver work can be found at: http://acert.ir.bbn.com/cvs/?group=netbsd primarily in: http://acert.ir.bbn.com/viewvc/netbsd/netbsd/src/sys/dev/usb/ Is there a consolidated patch file that would make it easier to apply against the current NetBSD source tree? cheerio Berndt pgp62zeOKS7gc.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USB progress
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 rate, and the others are fine. So they are getting past that same point in the sequence with no trouble, and they're also not all failing ~60k samples before the end... It's probably indeed not very critical to figure it out, but it does strike me as odd that it's unreliable in this particular way. Joanne ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD USB progress
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 at least 16 MB/s well. According to benchmark_usb.py (and test_digital_loopback*) in gnuradio-examples, we are getting 32 MB/s throughput (16 in each direction). Also, the test_usrp_standard_rx and test_usrp_standard_tx programs indicate we're almost getting 25.6 MB/s one-way (decimation 10 and interpolation 20), typically with 0-2 overruns or underruns. This is much improved over ~4 MB/s but the next step is to work on optimizing what's needed to reach 32 MB/s reading or writing. If you're interested, the current driver work can be found at: http://acert.ir.bbn.com/cvs/?group=netbsd primarily in: http://acert.ir.bbn.com/viewvc/netbsd/netbsd/src/sys/dev/usb/ Also, interestingly, benchmark_usb always fails for 2 MB/s even though the other rates are fine. I don't know yet why that might be, but it always looks about like this, always around 940k samples: gr_check_lfsr_32k: enter_SEARCHING at offset0 (0x) gr_check_lfsr_32k: enter_LOCKED at offset 1452 (0x05ac) gr_check_lfsr_32k: enter_SEARCHING at offset 947028 (0x000e7354) usb_throughput = 2M ntotal= 100 nright= 945576 runlength = 0 delta = 100 FAILED Joanne ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USB progress
On Mon, Jun 26, 2006 at 02:39:32PM -0400, Joanne M Mikkelson wrote:
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 at least 16 MB/s well. According to benchmark_usb.py
(and test_digital_loopback*) in gnuradio-examples, we are getting 32
MB/s throughput (16 in each direction). Also, the test_usrp_standard_rx
and test_usrp_standard_tx programs indicate we're almost getting 25.6
MB/s one-way (decimation 10 and interpolation 20), typically with 0-2
overruns or underruns.
Definitely improved!
This is much improved over ~4 MB/s but the next step is to work on
optimizing what's needed to reach 32 MB/s reading or writing. If
you're interested, the current driver work can be found at:
http://acert.ir.bbn.com/cvs/?group=netbsd
primarily in:
http://acert.ir.bbn.com/viewvc/netbsd/netbsd/src/sys/dev/usb/
Also, interestingly, benchmark_usb always fails for 2 MB/s even
though the other rates are fine. I don't know yet why that might be,
but it always looks about like this, always around 940k samples:
gr_check_lfsr_32k: enter_SEARCHING at offset0 (0x)
gr_check_lfsr_32k: enter_LOCKED at offset 1452 (0x05ac)
gr_check_lfsr_32k: enter_SEARCHING at offset 947028 (0x000e7354)
usb_throughput = 2M
ntotal= 100
nright= 945576
runlength = 0
delta = 100
FAILED
Joanne
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.
test_usrp_standard_{tx, rx} seem to work fine, however.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD GNU Radio 2.8 packages
G'day, NetBSD users may be interested to learn that GNU Radio 2.8 modules are now available from the NetBSD Packages Collection (pkgsrc). I'm currently working on getting ham/gnuradio-audio-jack and ham/gnuradio-audio-portaudio. There are some issues that I need to resolve before they can be submitted. 73, Berndt VK5ABN pgpMrCTkVuKhO.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD binary packages
G'day, GNU Radio binary packages are now available for NetBSD-2.1 and NetBSD-3.0 i386 platforms. For more info visit link below: ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/ham/README.html Enjoy, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
