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 [EMAIL PROTECTED] _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
