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

[LRK]

On Sun, May 07, 2006 at 12:29:15PM +0930, Daniel O'Connor wrote:
> On Saturday 06 May 2006 23:35, LRK wrote:
> > I would like to run GR under FreeBSD so I am looking forward to your
> > progress on this.
> >
> >
> > Under FreeBSD (and probably NetBSD) the ugen(4) device is generic and gets
> > assigned to any unknown device. I would suggest you look into getting a
> > number assigned to the USRP and a name assigned for it, say usrp(4). Any
> > application more serious than experimental would seem to justify it.
> 
> Creating a kernel driver won't magically make things go faster, it is also 
> more complicated as you have to write a driver and the code to talk to it..
> 
> IMO the best solution would be AIO but that isn't very portable, next best is 
> hacking ugen to not have so many restrictions. 
> 
> This is because of the USB IO model - the problem is that ugen does not know 
> how big a block of data to request from the device, and unlike more 
> traditional devices it does make a difference (since USB allows you to 
> request certain size transfers as well as allow short transfers). The fix for 
> ugen is to supply it with a hint to say what size transfer it should queue up 
> after the current one has been done. This gives you more transfers in flight 
> and greatly improves throughput.
> 
> There have been attempts to fix ugen in FreeBSD to do this but it didn't work 
> very well because the API was not extended to provide the hint so it was 
> backed out.
> 
> 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
responds with a code saying it will take a device if no other driver wants
it. A copy of ugen named usrp could respond only to being offered a USRP
but the USRP should have a unique number assigned rather than the general
one used now. If there was a driver unique to the USRP, it would not need
to work with other USB devices, thus my suggesting that direction.

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.

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.

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.


-- 
LRK
address@hidden