Raspberry Pi, Real-Time and Ada

Raspberry Pi, Real-Time and Ada

[Rego, P.]

Hi guys,

Is it possible to run Real-Time applications on Raspberry Pi (specially in Ada)? Yesterday I began to read the RPi documentation, and discovered that several (actually all that I found) I/O libraries available to access GPIOs (mostly written in C and Python) are not Real-Time, and even the Raspbian Debian distribution is not intended to run RT applications, so it's not built for it. 

One idea could be using the CONFIG_PREEMPT_RT Linux patch, so I think I would have to recompile the Raspbian kernel. Is it reliable for an ARM11? I mean, can I work on it as an RTOS-like this way? And also I think that I would have to rewrite the I/O libraries (no problem, but it's also an overhead).

Or the other option could be using a real RTOS. I've seen some posts about ChibiOS/RT, Xenomai and FreeRTOS, but they don't seem to have Ada available. 

So I would much appreciate your opinions.

Best regards,
Rego.

Re: Raspberry Pi, Real-Time and Ada

[Stephen Leake]

"Rego, P." <pvrego@gmail.com> writes:

> Is it possible to run Real-Time applications on Raspberry Pi
> (specially in Ada)? Yesterday I began to read the RPi documentation,
> and discovered that several (actually all that I found) I/O libraries
> available to access GPIOs (mostly written in C and Python) are not
> Real-Time, and even the Raspbian Debian distribution is not intended
> to run RT applications, so it's not built for it.

You seem to be using "Real-Time" in some special technical way, as
opposed to the general definition "meeting the application timing
deadlines".

Using the general definition, if your application has deadlines with
tolerances on the order of 0.1 seconds, then the answer is clearly
"yes".

For tighter tolerances, you'd have to measure the actual performance,
and possibly use an enhanced kernel as you discussed.

"Premature optimization is the root of all evil"

-- 
-- Stephe

Re: Raspberry Pi, Real-Time and Ada

[Dmitry A. Kazakov]

On Thu, 06 Feb 2014 01:50:40 -0600, Stephen Leake wrote:

> "Rego, P." <pvrego@gmail.com> writes:
> 
>> Is it possible to run Real-Time applications on Raspberry Pi
>> (specially in Ada)? Yesterday I began to read the RPi documentation,
>> and discovered that several (actually all that I found) I/O libraries
>> available to access GPIOs (mostly written in C and Python) are not
>> Real-Time, and even the Raspbian Debian distribution is not intended
>> to run RT applications, so it's not built for it.
> 
> You seem to be using "Real-Time" in some special technical way, as
> opposed to the general definition "meeting the application timing
> deadlines".
> 
> Using the general definition, if your application has deadlines with
> tolerances on the order of 0.1 seconds, then the answer is clearly
> "yes".
> 
> For tighter tolerances, you'd have to measure the actual performance,
> and possibly use an enhanced kernel as you discussed.

Absolutely.

Last time I checked there were ARM GPIO drivers for Linux, so I see no
problem with RT except for possibly poor performance of the GPIO.

It really depends rather on the hardware than the OS. In particular on how
many AD/DA converters are physically present (to be shared between analogue
inputs).

Note that if you have, say, one AD multiplexed to four inputs, then no
matter how RT your OS is, the latency between 1st and 4th inputs will be no
less than 4 conversion times. Taking typical values 40us * 4 = 0.8ms. Now
if inputs considered synchronous, this is also the jitter.

BTW, many boards do not even have all GPIO pins soldered. You should check
if Raspberry Pi has ones you wanted to use.

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

Re: Raspberry Pi, Real-Time and Ada

[Simon Clubley]

On 2014-02-06, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
> Last time I checked there were ARM GPIO drivers for Linux, so I see no
> problem with RT except for possibly poor performance of the GPIO.
>
> It really depends rather on the hardware than the OS. In particular on how
> many AD/DA converters are physically present (to be shared between analogue
> inputs).
>

Oh, Dmitry, not this again. :-)

You may live in a analogue world, but for many (most ?) people, their
GPIO lines are used in a mainly digital mode with little A/D conversion
involved.

For myself, I do the odd A/D conversion on a GPIO line, but the vast
majority of the time they are used in a pure binary 0/1 digital mode.

I've seen a number of reports about how much overhead there is within
Linux when trying to drive the GPIO lines on the Raspberry Pi, so I can
easily believe that it _is_ a OS level issue.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

Hello Simon,
On Thursday, February 6, 2014 10:16:40 AM UTC-3, Simon Clubley wrote:
> I've seen a number of reports about how much overhead there is within
> Linux when trying to drive the GPIO lines on the Raspberry Pi, so I can
> easily believe that it _is_ a OS level issue.
Maybe these reports are available on the internet? It would be very good to take a look on them if possible. 

Thanks.

Re: Raspberry Pi, Real-Time and Ada

[Simon Clubley]

On 2014-02-06, Rego, P. <pvrego@gmail.com> wrote:
> Hello Simon,
> On Thursday, February 6, 2014 10:16:40 AM UTC-3, Simon Clubley wrote:
>> I've seen a number of reports about how much overhead there is within
>> Linux when trying to drive the GPIO lines on the Raspberry Pi, so I can
>> easily believe that it _is_ a OS level issue.
> Maybe these reports are available on the internet? It would be very good to take a look on them if possible. 
>
> Thanks.

I went back and had a closer look at this. (I've never actually used
Linux to drive GPIO lines as I either use a dedicated RTOS or just
write the code for bare metal mode).

It appears there are two ways of accessing the GPIO lines on the
Raspberry Pi under Linux: either via the /sys/class/gpio interface
or directly via memory mapped I/O.

It looks like all the types of performance comments I remember come
from the first access method and that you can get far better access
times using the second method.

Which method are you using ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

> I went back and had a closer look at this. (I've never actually used
> Linux to drive GPIO lines as I either use a dedicated RTOS or just
> write the code for bare metal mode).
> It appears there are two ways of accessing the GPIO lines on the
> Raspberry Pi under Linux: either via the /sys/class/gpio interface
> or directly via memory mapped I/O.
> It looks like all the types of performance comments I remember come
> from the first access method and that you can get far better access
> times using the second method.
> Which method are you using ?

At this time in RPi, none of them. For now I am still studying the board before coding, as I should port an application to it in the next days. But I am still evaluating if the RPi serves to my app. Timing constraints are the top concern. But there as others, for example I just have 1 PWM exposed in RPi and I would need at least 4; this is a minor concern if I can control some GPIOs using timers, or use an external board to do it for me, but it would be better if I had more PWM.

Rego.

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

Hello Dmitry,
On Thursday, February 6, 2014 5:44:03 AM UTC-3, Dmitry A. Kazakov wrote:
> Last time I checked there were ARM GPIO drivers for Linux, so I see no
> problem with RT except for possibly poor performance of the GPIO.
> It really depends rather on the hardware than the OS. In particular on how
> many AD/DA converters are physically present (to be shared between analogue
> inputs).
> Note that if you have, say, one AD multiplexed to four inputs, then no
> matter how RT your OS is, the latency between 1st and 4th inputs will be no
> less than 4 conversion times. Taking typical values 40us * 4 = 0.8ms. Now
> if inputs considered synchronous, this is also the jitter.
Ok.

> BTW, many boards do not even have all GPIO pins soldered. You should check
> if Raspberry Pi has ones you wanted to use.
Yes, that's a point. Yesterday I found out that it does not have. I needed to use some PWM outputs, but RPi only exposes one, so I will have to use some timers for emulating the others, which is not very precise, but at this point I don't need much accuracy.

Thanks.

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

Hello Stephen,

On Thursday, February 6, 2014 4:50:40 AM UTC-3, Stephen Leake wrote:
> You seem to be using "Real-Time" in some special technical way, as
> opposed to the general definition "meeting the application timing
> deadlines".
I really meant "meeting the application timing deadlines".

> Using the general definition, if your application has deadlines with
> tolerances on the order of 0.1 seconds, then the answer is clearly
> "yes".
Very slow, but based on what?

> For tighter tolerances, you'd have to measure the actual performance,
> and possibly use an enhanced kernel as you discussed.
Measuring could be excelent. Do you know some tools that I could use for measuring the RPi performance?

Thanks!

Re: Raspberry Pi, Real-Time and Ada

[Stephen Leake]

"Rego, P." <pvrego@gmail.com> writes:

> On Thursday, February 6, 2014 4:50:40 AM UTC-3, Stephen Leake wrote:
>> You seem to be using "Real-Time" in some special technical way, as
>> opposed to the general definition "meeting the application timing
>> deadlines".
> I really meant "meeting the application timing deadlines".

Ok, good.

What is your application?

What are your timing requirements?

>> Using the general definition, if your application has deadlines with
>> tolerances on the order of 0.1 seconds, then the answer is clearly
>> "yes".
> Very slow, but based on what?

I think you are asking:

"How do you know the RPi can meet 0.1 second tolerances?"

I've seen one running Emacs, and it responds well to keyboard commands.
Humans notice delays longer than 0.1 seconds, so that's my metric.

Why do you think 0.1 seconds is "slow"?

If the application is flying a spacecraft to Jupiter, then 1 day is
"fast" during the coast phase, when nothing much is happening.

"fast" and "slow" are totally determined by the application.

>> For tighter tolerances, you'd have to measure the actual performance,
>> and possibly use an enhanced kernel as you discussed.
> Measuring could be excelent. Do you know some tools that I could use
> for measuring the RPi performance?

That's heavily application dependent.

If your application is some sort of control system, then it reads
inputs, computes, and writes outputs.

Using an oscilloscope, measure the time from an input signal to a
related output signal.

--
-- Stephe

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

On Friday, February 7, 2014 6:28:23 AM UTC-2, Stephen Leake wrote:
> Ok, good.
> What is your application?

In short, drones. 

> What are your timing requirements?
For the next application I think I will need achieve 1 ms for I/O access in hard RT, and up to 100 us for pure computation for soft RT.

> I think you are asking:
> "How do you know the RPi can meet 0.1 second tolerances?"
> I've seen one running Emacs, and it responds well to keyboard commands.
> Humans notice delays longer than 0.1 seconds, so that's my metric.

Ok, it makes sense. In this case, I also get to run GPS on it, and I cannot feel any delay to the keyboard.

> Why do you think 0.1 seconds is "slow"?
> If the application is flying a spacecraft to Jupiter, then 1 day is
> "fast" during the coast phase, when nothing much is happening.
> "fast" and "slow" are totally determined by the application.

Indeed. Yes, I will need much faster.

> That's heavily application dependent.
> If your application is some sort of control system, then it reads
> inputs, computes, and writes outputs.
> Using an oscilloscope, measure the time from an input signal to a
> related output signal.

I was thinking more on some sw tools made for measuring hw performance. A time ago I used some tools for evaluating performance of parallel machines with MPI and OpenMP (I don't remember the names now), thought it could have some of these in RPi. Anyway measuring the outputs would be a very good starting point.

--
Rego.

Re: Raspberry Pi, Real-Time and Ada

[Stephen Leake]

"Rego, P." <pvrego@gmail.com> writes:

> On Friday, February 7, 2014 6:28:23 AM UTC-2, Stephen Leake wrote:
>> Ok, good.
>> What is your application?
>
> In short, drones. 
>
>> What are your timing requirements?
> For the next application I think I will need achieve 1 ms for I/O
> access in hard RT, and up to 100 us for pure computation for soft RT.

I don't understand; the timing for "soft RT" is stricter than the timing
for "hard RT". What do "soft" and "hard" mean here?

Hmm. Perhaps they just mean "hardware" and "software"; I don't see why
that's a useful distinction.

But you are optimizing prematurely again; these are times for small
parts of the overall control cycle. You need to start from the top.

How fast does the overal control cycle need to run? Once every second?
1000 times a second?

For spacecraft, this is based on a stability and pointing accuracy
analysis; if the control cycle were slower, the spacecraft would not be
stable, or would not point accurately enough. 10 Hz is usually adequate. 

What does the control cycle in a drone do? I suspect the plane is
basically stable by the design of the wings and tail, and the control
system is just running the steering. 

If the drone is teleoperated, the requirement is the human sensing time;
you push the joystick, you want the plane to respond "quickly". Which
gives control cycle times of 0.1 seconds = 10 Hz. Although 1 second
would be tolerable.

If the drone is autonomous, that analysis does not apply. If the drone's
mission is to take pictures of targets, you can derive timing requirements
from the speed of the drone in flight and the speed of the camera. That
also gives location and pointing accuracy requirements; do you have GPS
on the drone? How does it know where the camera is pointed?

> Indeed. Yes, I will need much faster.

Based on what analysis?

-- 
-- Stephe

Re: Raspberry Pi, Real-Time and Ada

[Dmitry A. Kazakov]

On Sat, 08 Feb 2014 02:28:43 -0600, Stephen Leake wrote:

> "Rego, P." <pvrego@gmail.com> writes:
> 
>> Indeed. Yes, I will need much faster.
> 
> Based on what analysis?

Right. For a mechanical process 1ms is enough for a very fast and very
light system. Bigger is the mass slower is the cycle F=ma, T=V/a. Typically
10ms is more than enough for most purposes.

0.1ms sounds like a burning or explosion process. When people want less
than 1ms, I ask them if they are building a bomb... (:-))

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

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

On Saturday, February 8, 2014 5:28:43 AM UTC-3, Stephen Leake wrote:
> I don't understand; the timing for "soft RT" is stricter than the timing
> for "hard RT". What do "soft" and "hard" mean here?
> Hmm. Perhaps they just mean "hardware" and "software"; I don't see why
> that's a useful distinction.

Well... I meant soft real-time and hard real-time; but that's all pure academic.

> But you are optimizing prematurely again; these are times for small
> parts of the overall control cycle. You need to start from the top.
I did not understand.

> How fast does the overal control cycle need to run? Once every second?
> 1000 times a second?
I think this would give a good response; but for the entire control cycle.

> For spacecraft, this is based on a stability and pointing accuracy
> analysis; if the control cycle were slower, the spacecraft would not be
> stable, or would not point accurately enough. 10 Hz is usually adequate. 
> What does the control cycle in a drone do? I suspect the plane is
> basically stable by the design of the wings and tail, and the control
> system is just running the steering.
> Based on what analysis?

Actually it depends highly on your design. My perception is that as smaller is the drone, faster you should be able to control it. For example, wonder a quadcopter 10m high, falling down, maybe because you (controller) lost communication. An autonomous recover-to-ground algorithm should in 1s: 1) identify communication is lost; 2) assume override; 3) read sensors (as always); 4) calculate the best landing; 4) command devices and land. Using a complete model you would need to solve some conditions for a 12-dimensions model. With 10Hz I would have only 100 iterations in 1s. And all this should happen before the human sense realizes (so 1s is quite fast for us).

> If the drone is teleoperated, the requirement is the human sensing time;
> you push the joystick, you want the plane to respond "quickly". Which
> gives control cycle times of 0.1 seconds = 10 Hz. Although 1 second
> would be tolerable.
> If the drone is autonomous, that analysis does not apply. If the drone's
> mission is to take pictures of targets, you can derive timing requirements
> from the speed of the drone in flight and the speed of the camera. That
> also gives location and pointing accuracy requirements; do you have GPS
> on the drone? How does it know where the camera is pointed?

No camera for now. But it should be able to have one.

Regards.

Re: Raspberry Pi, Real-Time and Ada

[Stephen Leake]

"Rego, P." <pvrego@gmail.com> writes:

>> For spacecraft, this is based on a stability and pointing accuracy
>> analysis; if the control cycle were slower, the spacecraft would not be
>> stable, or would not point accurately enough. 10 Hz is usually adequate. 
>> What does the control cycle in a drone do? I suspect the plane is
>> basically stable by the design of the wings and tail, and the control
>> system is just running the steering.
>> Based on what analysis?
>
> Actually it depends highly on your design. 

Yes it does; that was my main point.

>My perception is that as
> smaller is the drone, faster you should be able to control it. For
> example, wonder a quadcopter 10m high, falling down, maybe because you
> (controller) lost communication. An autonomous recover-to-ground
> algorithm should in 1s: 1) identify communication is lost; 

Assume no communications in 3 cycles = lost; that leaves 7 cycles.

>2) assume
> override; 3) read sensors (as always); 4) calculate the best landing;

That all takes less than 1 cycle.

> 4) command devices and land. 

No problem; each of the 7 remaining cycles keeps the quadcopter level,
and moves it one step closer to the ground.

> Using a complete model you would need to solve some conditions for a
> 12-dimensions model. 

If that takes longer than 100 ms, you need a faster on-board computer.

> With 10Hz I would have only 100 iterations in 1s.

10 iterations; 10 Hz = 10 cycles per second = 100 ms per cycle.

>And all this should happen before the
> human sense realizes (so 1s is quite fast for us).

Right.

So 10 Hz is adequate. 5 Hz is probably ok as well, if your computer can
only manage that.

This is a quad-copter, which is stabilized solely by controlling the
rotor blades, and thus needs active control. 

I was talking earlier about a wing-and-tail design, which requires no
active stabilization; paper airplanes manage to fly :).

-- 
-- Stephe

Re: Raspberry Pi, Real-Time and Ada

[Dmitry A. Kazakov]

On Thu, 6 Feb 2014 13:04:19 -0800 (PST), Rego, P. wrote:

>> Using the general definition, if your application has deadlines with
>> tolerances on the order of 0.1 seconds, then the answer is clearly
>> "yes".
> Very slow, but based on what?

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.
 
>> For tighter tolerances, you'd have to measure the actual performance,
>> and possibly use an enhanced kernel as you discussed.

> Measuring could be excelent. Do you know some tools that I could use for
> measuring the RPi performance?

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. The second test is to measure how close delay 1.0 is to
1 second using Ada.Real_Time.Clock. The deviation from 1s tells how coarse
OS programmable timer services are. There are OS means to attune that (on
the performance cost).

Once you have Ada.Real_Time.Clock it is no problem to measure the control
loop your system does. Usually you would measure several thousands of
cycles to get min, max and average times. If you have background services
to run, you do measures under load (with other services) and without load.

The OS latencies (in the driver etc) is a more difficult stuff. If the OS
does not have means to measure these times (VxWorks has), you still can
estimate these by subtracting known durations from the whole cycle time.
You can also use digital outputs which are considerably faster than
analogue ones and the oscilloscope, etc. You can calibrate digital output
times by measuring many thousands of write-cycles and taking the mean.

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

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

On Friday, February 7, 2014 6:42:41 AM UTC-2, Dmitry A. Kazakov 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.

It turns things much better. 

> Ada has everything you need for that.

That is always as good as it sound :-)

> 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.
Ok.

> 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. The second test is to measure how close delay 1.0 is to
> 1 second using Ada.Real_Time.Clock. The deviation from 1s tells how coarse
> OS programmable timer services are. There are OS means to attune that (on
> the performance cost).
> Once you have Ada.Real_Time.Clock it is no problem to measure the control
> loop your system does. Usually you would measure several thousands of
> cycles to get min, max and average times. If you have background services
> to run, you do measures under load (with other services) and without load.
Great. I think it will cover most of what I need to know.

> The OS latencies (in the driver etc) is a more difficult stuff. If the OS
> does not have means to measure these times (VxWorks has), you still can
> estimate these by subtracting known durations from the whole cycle time.

Do you remember how can be done on VxWorks? (it could be also good to test it on VxWorks just for curiosity). So I can try to find an alike alternative, maybe in Xenomai it is available.

> You can also use digital outputs which are considerably faster than
> analogue ones and the oscilloscope, etc. You can calibrate digital output
> times by measuring many thousands of write-cycles and taking the mean.
Ok. This will complement the tests. Great.

--
Regards,
Rego.

Re: Raspberry Pi, Real-Time and Ada

[Dmitry A. Kazakov]

On Fri, 7 Feb 2014 04:34:47 -0800 (PST), Rego, P. wrote:

> Do you remember how can be done on VxWorks? (it could be also good to test
> it on VxWorks just for curiosity). So I can try to find an alike
> alternative, maybe in Xenomai it is available.

System Viewer and Performance Profiler, if I correctly remember the names.
I don't have a license at the time.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

On Friday, February 7, 2014 10:59:46 AM UTC-2, Dmitry A. Kazakov wrote:
> System Viewer and Performance Profiler, if I correctly remember the names.
> I don't have a license at the time.

Ok, I will take a look. Thanks.

--
Regards, 
Rego.

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

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

Re: Raspberry Pi, Real-Time and Ada

[Dmitry A. Kazakov]

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

Re: Raspberry Pi, Real-Time and Ada

[Rego, P.]

On Saturday, February 8, 2014 5:56:02 AM UTC-3, Dmitry A. Kazakov wrote:

> 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).

The Ada implementation? 

> 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

ok

> 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.
What is HPET?

> 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.
Mine is an I7.

> 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).

Ok. I will try.

Regards

Re: Raspberry Pi, Real-Time and Ada

[Dmitry A. Kazakov]

On Mon, 10 Feb 2014 10:29:12 -0800 (PST), Rego, P. wrote:

> On Saturday, February 8, 2014 5:56:02 AM UTC-3, Dmitry A. Kazakov wrote:
> 
>> 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).
> 
> The Ada implementation? 

The system calls it makes, so that you can track down the time source.

>> 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.
> What is HPET?

http://en.wikipedia.org/wiki/High_Precision_Event_Timer

TSC is

http://en.wikipedia.org/wiki/Time_Stamp_Counter

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