Re: Raspberry Pi, Real-Time and Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 7 Feb 2014 15:11:20 -0800 (PST), Rego, P. wrote:

>> I don't think that 10ms would be a problem even for ARM.
>> On an Intel board 200µs loops (read inputs, calculate, write outputs) are
>> doable.
>> Ada has everything you need for that.
>> The main problem is how good the RT clock is. Windows and VxWorks typically
>> have miserable RT clock services on x86. x86 Linux has a decent one.
>> Regarding ARM Linux, I didn't tested its clock, so I cannot tell. The
>> primary test is to call Ada.Real_Time.Clock twice and to compare if the
>> reading is same. If they are you should look for an alternative
>> implementation of. 
> 
> BTW, now I have done a fast test using 
> 
> with Ada.Real_Time; use Ada.Real_Time;
> with Ada.Text_IO;
> 
> procedure My_Clock is
>    First_Time : Time;
>    Second_Time : Time;
>    F_Duration : Time_Span;
>    Time_Duration : Duration;
> 
> begin
>    First_Time := Ada.Real_Time.Clock;
>    Second_Time := Ada.Real_Time.Clock;
>    F_Duration := Second_Time - First_Time;
>    Time_Duration := To_Duration (F_Duration);
> 
>    Ada.Text_IO.Put_Line (Duration'Image (Time_Duration));  
> 
> end My_Clock;
> 
> and the result was in average 17us for the RPi (with Raspbian without the
> preemptive patch), with a variation of 1 us (for just a few executions),

That looks pretty much slow for a 700MHz processor. You should take a look
what exactly the implementation is (in s-oprim.adb, I suppose).

> while the same code running on a Windows 7x64 machine was sometimes 0,
> sometimes 366ns (49 times faster).

If you look at the implementation of you see that it is based on the
performance counter:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904%28v=vs.85%29.aspx

MS does not tell which time source they use for this function. There are
many on an Intel board. That you have 0 to 366ns (which is very poor for an
Intel machine) indicates that probably your machine uses the HPET. HPET
runs at 25MHz or so, which is pitiful for a GHz machine.

I suppose there are some architectural problems with using the TSC on
multi-core machines which is why older single-core Windows machines tend to
have better clocks.

Anyway, you could try to play a bit with the BIOS and BOOT.INI in order to
force Windows not to use HPET (or even worse, the programmable timer).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de