Re: delay until and GNAT - expand

[Joel Sherrill <joel@OARcorp.com>]

In article <rracine.13.0007AF82@draper.com>,
  rracine@draper.com (Roger Racine) wrote:
> >In article <rracine.12.00086B05@draper.com>,
> >  rracine@draper.com (Roger Racine) wrote:
>
> >> The implementation of "delay", given today's processor speeds, is
pretty good.
> >>  I have recently single stepped my way (in assembly) through it,
and while I
> >> did not count the instructions, it had to be on the order of 100
instructions.
> >>
> >> So, given a good real-time operating system and a reasonably fast
processor, a
> >> reasonable upper limit would probably be close to 1 microsecond
(conservative
> >> estimate).
> >>
> >> I am surprised GNAT documentation does not have this, except that
the number
> >> will be different for every underlying OS.
> >>
> >> Roger Racine
>
> >This is a highly misleading figure. The completion of a delay, in the
sense
> >that we are talking about, requires a preemptive context switch. To
expect
> >this to happen in 1 microsecond when running over an operating system
like
> >Unix, or even over a light real time executive is wildly optimistic.
>
> >I am not sure what you are measuring, but it is quite wrong. We don't
document
> >upper limits for such things in the GNAT manual, because it is
impractical to
> >do so in almost all operating systems contexts, since we depend on
the
> >underlying OS, and this information is not available for the OS.
>
> It is not misleading at all.  It is a consequence of the speed of
today's
> processors.  Back a few years (1983), it was reasonable to expect a
simple
> delay 0.0, which is what the issue is about, to take somewhere near
100 -200
> microseconds on a real-time OS.  This included the context switch, but
not the
> activities of other tasks.  Is this the meaning of the metric in
D.8(10,11)?
>
> I was somewhat surprised to see numbers, for context switches, in the
range of
> 1 microsecond, but not when I thought of the current speed of
processors.  And
> the metric is for processor clock cycles.  I am assuming waiting for
memory
> does not count, but even if that is true, the result will not be very
much
> longer.
>
> Note that I said, "given a good real-time operating system".  That
does
> not include any form of Unix (with the possible exception of LynxOS
and any
> other real-time versions; I have not looked at their documentation
recently).
>
> I understand why compiler vendors can not document upper limits for
host-based
> systems.  I would think that VxWorks and RTEMS could have the bounds
> documented.  And something like "GNAT takes xxx clock cycles + the
underlying
> operating system context switch" would meet the spirit of the RM.  I
know Wind
> River publishes their bounds.  It is quite reasonable to have users of
the
> metrics look at other documentation, as long as it is referenced.
>
> Roger Racine

This information is documented for some RTEMS targets.  But better
than this is that the test suite used to generate this information
is included with RTEMS and you can generate these numbers yourself
on your target hardware.  The context switch performance test in
particular is "tm26".  The mvme167 BSP reports a basic context
switch at 3 microseconds on a 25 Mhz board.

An important thing to remember is that often these older CPUs look
quite good at context switches compared to newer high performance
RISC CPUs.  Context switches tend to be memory bound and RISC CPUs
tend to have more state to save.  But then again new RISC CPUs have
incredibly high clock rates which covers up a lot. :)

--joel
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985



--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---