[IPython-User] Ipython for Angstrom
Thu Sep 9 14:38:35 CDT 2010
David is right on about where the 250 Hz comes from. My grad student
is playing with different real-time kernels and such. I will pass
these suggestions on to him.
Thanks for you thoughts.
On Wed, Sep 8, 2010 at 9:42 AM, David Cournapeau <firstname.lastname@example.org> wrote:
> On Wed, Sep 8, 2010 at 12:09 PM, Ryan Krauss <email@example.com> wrote:
>> Thanks. Yea, I eventually got IPython to run on the BeagleBoard
>> without a problem.
>> But we hit a roadblock with deadtime in between serial transmissions.
>> My work at this point depends on being able to send 5-10 bytes of data
>> back and forth to a microcontroller that is doing real-time control
>> with update frequencies of 500-1000 Hz. We are running a test where
>> we just echo data back and forth with the micro to test the loop time.
>> We were hoping that the BeagleBoard would be an improvement over a
>> laptop mainly because there is less stuff going on and more control
>> over the hardware. It hasn't worked out yet. And we have struck out
>> with several approaches to reducing the deadtime. The PC just seems
>> to sit there doing nothing. The annoying thing is that windows can
>> run the code with 500 Hz update frequencies without a problem. We
>> haven't found a linux approach that can do better than around 250 Hz.
> Did you try the low-latency kernels with real time patches ? They can
> be used quite successfully for almost guaranteed (worst case) ~ 1 ms
> latency. It may be hard to do so in pure python, though - you may want
> to run the "thing" which needs to run fast in a separate thread with
> its own scheduling priority (SCHED_FIFO, see man 2
> sched_setscheduler), written in pure "computational" C (without
> malloc, locks and other system calls). Ideally, you should lock the
> memory of that thread in memory to avoid page faults (man mlock,
> Also, what is your tick value for your kernel ? 250 Hz is the default
> value for CONFIG_HZ on many kernels, but can be set lower - keeping in
> mind that you can go below that rate anyway using the techniques above
> (which essentially boils down to - no system call at all in your high
> priority thread).
More information about the IPython-User