On Wed, Jul 27, 2011 at 4:16 PM, Thomas Tsou <tt...@vt.edu> wrote: > On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer <colby.bo...@gmail.com> > wrote: > > Hi all, > > I'm running a duplex system on the USRP1; using UHD drivers (about 1 > month > > old). For the sample rates, I have 640KHz to the USRP and 1MHz from the > > USRP. The turn around time for a simple amplitude detected signal is > approx > > 20ms, which is crazy high. Btw, I'm measuring the latency (approx) by > > observing the nitems_written() method for the block that produces samples > > for the sync. > > I'm running UHD and gnuradio with real time threading enabled and giving > the > > gnuradio app a nice of -20. Since this happens before any math occurs, I > > assume the kernel is lagging on this. Could switching to a modified > kernel > > with realtime improvement patches help? > > The short answer is that using the RT patch series won't perform any > magic and bring across the board reductions in measured latencies. The > longer answer is, of course, more complicated. If you want > straightforward solutions, try removing other peripherals from the USB > bus and disabling all power management (preferably from the kernel). > The latter can be particularly sinister when it comes to tracking down > latency bugs. > > Once upon a time, I wrote a kernel module to handle a hard interrupt > off of a parallel port and trigger responses from within kernel space > (out another pin) and userspace (submitting transfers to libusrp). An > external scope was was used for timing measurement. Response times > were on average in the single and 10's of microseconds respectively, > but differed drastically based on many factors. The main ones were CPU > load, power management, and other devices on the USB bus. > > When it comes to RT patches, you need to consider that the objective > is typically containing maximum latencies and not necessarily minimal > or average times. In certain cases, average latencies using RT code > may be even be higher than the mainline version. > > When I ran the tests, differences between mainline (somewhere around > 2.6.31) and RT series kernels were initially limited, but became > apparent when running at near 100% CPU load. In contrived cases, the > maximum latency on the normal kernel could increase without bound, > which would be more limited on the RT kernel. > > To sum it up, RT changes to the kernel will have an effect, but it > probably won't be immediately obvious. I would start from more obvious > areas - for example by seeing what power management is up to. > > Thomas >
Thanks for the detailed reply Thomas! I'll give the power management changes (from the kernel and from BIOS) a shot, then will try the ubuntu linux-rt kernel from their ubuntu studio repo. Are there any particular power options to change on the Kernel?
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
