From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.glorb.com!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!proxad.net!feeder1-2.proxad.net!usenet-fr.net!gegeweb.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Raspberry Pi, Real-Time and Ada Date: Sat, 8 Feb 2014 09:56:02 +0100 Organization: cbb software GmbH Message-ID: References: <5e8fad3a-94e6-4517-af54-db8b4146803e@googlegroups.com> <858uto3cj3.fsf@stephe-leake.org> <708ef9e4-b6a3-488b-a86d-b70c7de43ac2@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dRN93LcgZmpMwxQ2TpSF2g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 3576 Xref: number.nntp.dca.giganews.com comp.lang.ada:184722 Date: 2014-02-08T09:56:02+01:00 List-Id: 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