Isn't one of the problems that Linux is not a real time os, i.e., exact time scheduling is impossible? As far as I know, linux timers have an accuracy of 1ms (i.e. 1 jiffie in the kernel). If you want to have shorter delays, you use the udelay function and do a busy wait. Or is there something that I am missing?
Thomas On 2/26/06, Eric Blossom <[EMAIL PROTECTED]> wrote: > On Sun, Feb 26, 2006 at 11:16:17AM -0500, Clark Pope wrote: > > You'll want to strip out the extra receiver. The default fpga is 2 rx and 1 > > tx. You probably don't need the second RX for your application. You also > > may not need the halfband filter on your receiver. > > > > In the past I've stripped down to a single RX and got utilization down to > > about 30%. You'll probably be at 40% with one RX and one TX. > > The current code is (mostly) conditionally configured for number of Rx > and Tx channels. You can select 0, 1, 2 or 4 Rx, but right now, the > Tx is either 0 or 2. It's easy to fix. I'd welcome a patch (the Tx > should be conditionalized in the same style as the Rx). > > Take a look at usrp/fpga/toplevel/usrp_std/usrp_std.v, usrp_std.vh > and usrp_std_config_*.vh > > > As far as control logic. I've been planning something similar (open 802.11 > > mac) and I was thinking I could write a linux device driver to do a lot of > > the time critical stuff (agc, CA, etc.). Seems like one can poll some > > status lines from the FPGA frequently enough to do a lot of things. > > FYI, It's not clear that going to a driver is going to make too much > difference. It might, but I'd start with the user mode code. > Measure twice, cut once ;) > > There is some fairly straight-forward work that can be done to reduce > the latency of the user mode code, and that's probably a good first > step. This would also including enabling real-time scheduling for the > signal processing threads (SCHED_FIFO), reducing the amount of user > space buffering for the USRP (no need to mess with the generic > buffering in GNU Radio, it's not the problem), and transfering smaller > chunks of data across the user/kernel boundary (that that won't help > throughput!). > > Eric > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
