[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work we

From: Daniel O'Connor
Subject: Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD
Date: Sun, 7 May 2006 12:29:15 +0930
User-agent: KMail/1.9.1

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)

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

Attachment: pgp9pKBRhutVL.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]