Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD

[Daniel O'Connor]

On Monday 08 May 2006 01:18, LRK wrote:
> > A kernel driver could issue the multiple reads but it is a fair amount of
> > work to write one, and a bit of a waste if ugen could be extended instead
> > (hence benefiting other applications)
>
> Obviously it would be neat to extend ugen if the fixes were generic but if
> there need to be USRP-specific fixes they would best be done in a different
> module. Maybe I'm not understanding this but it looks to me like ugen just

That's where you are wrong. Writing a new module means writing (or copying) 
new code. If you copy ugen that means that any fixes for it need to get 
duplicated. Also, since the USRP isn't a "main stream" device it is likely OS 
changes will break it unless the maintainer is very active.

If you write a driver from scratch (which would be pretty silly given that 
ugen is almost exactly what you need) then you will take longer and have to 
fix more bugs.

> It also seems that the USRP tx and rx paths normally use the same block
> size after each open. If that is right, the driver could simply use that
> block size until the stream is closed, reading ahead on rx and providing
> flow control on tx.

Yes, but I think extended ugen to allow the user program to supply a hint to 
say "here is the block size, and keep reads queued" (via ioctl for exampe) is 
probably a lot simpler than creating a new driver.

> It appears the attempts to read the USRP at more than 4 MB/s just lock
> and transfer no data. Changing the 'read' in libusb to just return as
> though it had finished results in the 'test_usrp_standard_rx' giving
> similar results at all speeds including the pattern of overrun errors.
> The transfer rate calculated is very fast so the overrun error count
> seems to be a function of the USRP code rather than actual overruns.

The problem is that with no back to back transfer you are wasting slots (USB 
divides time into slots it will transfer data in). The limit of 4Mbytes/sec 
is because of the number of slots per second (divided by 2 I guess) multipled 
by the maximum block size for a bulk transfer.

> I guess this is getting much too complicated for the old guys like me
> to comprehend so I'll offer encouragement and await a solution, sooner
> the better.

It's OK, USB is complicated for younger minds too 8-)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

pgpdX9FXLWY95.pgp
Description: PGP signature