Re: Duration vs. Ada.Real_Time

[Marin David Condic <mcondic.auntie.spam@acm.org>]

Ted Dennison wrote:

> Hmmm. Now it sounds like you are talking about frequency vs.
> "resolution". :-)  When you say "accuracy", I think of things like clock
> drift. I'm currently dealing with networked realtime systems. Thus I've
> had problems associated with both the clock frequenceies and with the
> clock accuracy (clock drift between two machines that are trying to
> operate in lock-step).
>

Yes, drift and all that. I think we're really splitting hairs on this when I
think basically, we're talking the same thing. There are lots of ways a
clock can be inaccurate, right?

BTW: I've asked before when I was dealing with that same situation - two
machines that want to operate in lockstep. Do you know of any sort of
formal, published writings on algorithms to do this? We had a 1.024mSec
interrupt on both sides - no clock so no "delay until" - and some hardware
signalling between the two. We came up with ways of doing the sync, but I
kept thinking in the back of my mind that better/faster/easier ways of doing
it. Not horribly important now since I'm not dealing with that same problem,
but it has always bothered me enough to still want to read some books/papers
on the subject.

> GreenHills on vxWorks (x86 at least) uses a record type. The units of
> the smallest field are in microseconds. Thus if the frequency divides
> evenly into micros, you're OK.
>

That may be the internal representation they keep of the current time.
Somewhere there is some underlying hardware register or port or memory
address or something that when interrogated, gives you a collection of bits
that represents time from some epoc that is either a) scaled integer or b)
floating point (never seen a floating point - maybe you have?) If it is a
scaled integer (LSB represents One Fortnight?) If that's the case, there is
an exact representation as a fixed point type.

>
> However, I don't see how an Ada vendor could arrive at a good number
> ahead of time. Your best bet is probably to just use some ridiculously
> high resolution like Green Hills did. The frequency on vxWorks is
> something that can be changed by programs on the fly. Our (Ada) system

Why does the Ada vendor have to determine this "ahead of time"? What do you
mean? Lets say you are targeting board X which is either going to have some
standard clock fixture that always goes with boards of type X, or you are
going to have some custom one-off board where maybe the processor is common,
but everything else is rather unusual. If it is case one, the Ada
implementation uses that standard issue clock that is always on boards of
type X. (Seen that before with 1750a - it had two standard clocks - take
your pick.) If it is case two, you're going to have to provide some low
level packages that can be tailored to identify the time source, etc. and be
recompiled for that target. (Couldn't you have type Duration end-user
configurable? How else would you retarget?)

Sure the type two situation almost certainly blows your validation, but so
what? The vendor validates the compiler on some specific board with some
specific clock that supports the 0.020Sec requirement and that's that. The
end user has a similar board but a different clock? Hey! Once you break the
sticker on the case that says "Caution: No user servicable parts inside" -
the validation is null and void. Does anybody care? (Maybe the Military did
at one point in time - but if they don't require Ada, I can't see how they
could require *validated* Ada. Just rename the language and scratch out the
requirements you don't support, right? :-) Call it Bda?



>
> reads the requested frequency from a configuration file and sets it at
> startup. The default frequency is 60Hz. We have one system that uses the
> default, one that sets it at 240Hz, and one that sets it at 1,000Hz.
> With PC's getting faster all the time, I wouldn't be shocked to see
> folks wanting to use multiple KHz. Microseconds might even be too coarse
> by the end of the decade!

Well, O.K. here you are describing a situation where you are getting time
from a particular OS and you can't do much to change that. This is the same
as if you were getting it from Unix and you can't do anything about the
accuracy. I'd put this in the category of "impractical to have Duration
reflect the clock" category.

Its a little different if you are trying to implement your own vxWorks in
Ada and have direct contact with the hardware.

MDC
--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================