Re: [Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms
On Wed, Jul 27, 2011 at 4:16 PM, Thomas Tsou wrote: > On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer > 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
Re: [Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms
On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms
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? Thanks, Colby ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
