[IPython-User] Ipython for Angstrom

Ryan Krauss ryanlists@gmail....
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.

Ryan

On Wed, Sep 8, 2010 at 9:42 AM, David Cournapeau <cournape@gmail.com> wrote:
> On Wed, Sep 8, 2010 at 12:09 PM, Ryan Krauss <ryanlists@gmail.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,
> mlockall).
>
> 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).
>
> cheers,
>
> David
>


More information about the IPython-User mailing list