Re: Duration vs. Ada.Real_Time

Re: Duration vs. Ada.Real_Time

[Robert Dewar]

In article <8mac6.9236$R5.473526@news1.frmt1.sfba.home.com>,
  tmoran@acm.org wrote:
> >I figured that using Duration could give imprecise result.
So I wrote a
> >small program to print out Duration'Small.
>   Don't believe everything that a computer prints out.


Don't believe anything you read in CLA!

Of COURSE GNAT is correct when you ask it to print
Duration'Small, and I suggest believing it :-)

What is wrong is the incorrect idea that it has anything
to do with the resolution of the timer.


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Robert Dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

In article <3A71814B.7E8CCF60@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:
> So if you are concerned about portability, you'd use Duration
> only in applications where 20mSec of accuracy is sufficient.

This may be confusing, the question was not about precision
of Duration, it was about resolution of the timer

The value of Duration'Small is only an upper bound for
resolution, there is nothing in the RM that forbids an
implementation where clock only updates every second (and
indeed do not be surprised if some Unix implementations
are like this).


For portability, your use
> of Real_Time should never assume accuracy greater that
20uSec. If you don't
> need portability, then you can rely on whatever the
implementation gives you
> for Duration'Small etc.
>
> MDC
>
> Atle R�stad wrote:
>
> > Hi
> >
> > I have some code that has a max of 30 milliseconds to
process, and need to
> > measure if this is possible. But the requirement for
Duration is that
> > Duration'Small must be less then 20 milliseconds, and
> > Ada.Real_Time.Time_Unit must be less then 20 microseconds.
> >
> > I figured that using Duration could give imprecise result.
So I wrote a
> > small program to print out Duration'Small.
> >
> > I'm using gnat 3.12 and printed out both Duration'Small and
> > Real_Time.Time_Unit and they were both 1.0E-09. I thought
Duration'Small
> > would be larger then Real_Time.Time_Unit but they were the
same.
> >
> > Why should I use Real_Time when duration has the same
resolution?
> >
> > I will run the program on an Solaris 8. How will this
affect my time
> > measuring? What resolution can I expect?
> >
> > Thanks,
> > Atle
>
> --
>
===============================================================
=======
> 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]
>
===============================================================
=======
>
>


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

Ah! We appear to have here a good illustration of the difference between
accuracy and precision. Duration'Small represents the precision which
objects of type Duration can represent. The LSB has to be at least
20mSec. However, if the clock has accuracy no better than 1Sec, the LSBs
are meaningless. The precision exceeds the accuracy of the actual
device. (my misunderstanding of the original question.)

I would think that a reasonable implementation of Ada for realtime
systems would want to insure that the precision had some relationship to
the accuracy of the clock available. Obviously, for workstations/PCs
with a non-realtime OS, etc., you can't exactly insist that the platform
be changed for the language. But stating, for example, that the
precision of a time representation can go down to atto-seconds can
easily mislead one to believe that the measurement of time is going to
be something close to that precision.

Clearly, one needs to know two things: What is the accuracy of the
clock(s) available to me through the hardware/OS? (Talk to the hardware
manufacturer.) And what is the relationship between my hardware and the
Ada implementation I have? (Talk to the compiler vendor.) Id est, does
it do me any good to say "delay 0.020;" with a given compiler and target
system?

MDC

Robert Dewar wrote:

> This may be confusing, the question was not about precision
> of Duration, it was about resolution of the timer
>
> The value of Duration'Small is only an upper bound for
> resolution, there is nothing in the RM that forbids an
> implementation where clock only updates every second (and
> indeed do not be surprised if some Unix implementations
> are like this).

--
======================================================================
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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Ted Dennison]

In article <3A71E4F6.6D7015AD@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:

> I would think that a reasonable implementation of Ada for realtime
> systems would want to insure that the precision had some relationship
> to the accuracy of the clock available. Obviously, for
Do you mean "accuracy" or "frequency"?
...
> be changed for the language. But stating, for example, that the
> precision of a time representation can go down to atto-seconds can
> easily mislead one to believe that the measurement of time is going to
> be something close to that precision.

This gets back around to the issue we were discussing a couple of weeks
ago. If the language requires units of seconds, but the system's clock
used some incompatable system like Hz (eg: 60 Hz, which can't be
represented exactly in terms of fixed-point seconds), then you (or at
least *I*) would actually prefer a much higher precision, so that your
error in representation isn't so great when you start to do math with it.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Keith Thompson]

Ted Dennison <dennison@telepath.com> writes:
[...]	
> This gets back around to the issue we were discussing a couple of weeks
> ago. If the language requires units of seconds, but the system's clock
> used some incompatable system like Hz (eg: 60 Hz, which can't be
> represented exactly in terms of fixed-point seconds), then you (or at
> least *I*) would actually prefer a much higher precision, so that your
> error in representation isn't so great when you start to do math with it.

An implementation could easily declare type Duration in such a way
that 1.0/60.0 is exactly representable.

On the other hand, you probably don't want Duration to have that kind
of dependency on a particular system.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
MAKE MONEY FAST!!  DON'T FEED IT!!

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

Keith Thompson wrote:

> An implementation could easily declare type Duration in such a way
> that 1.0/60.0 is exactly representable.
>
> On the other hand, you probably don't want Duration to have that kind
> of dependency on a particular system.

Why not? For a specific target that is going to have a specific clock used for
timing of delays, etc., Duration can be an exact line-up with that clock. If
the implementation goes to another target, you'd have to change the declaration
of Duration to match its clock. What would be wrong with dependency on that
sort of system? (Presumption being that in both cases, the clock has a
granularity less than 20mSec so it is within the standard.)

This is assuming we are talking about realtime compilers as opposed to
something that targets, say, Unix & the time source is of questionable value.

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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

Ted Dennison wrote:

> In article <3A71E4F6.6D7015AD@acm.org>,
>   Marin David Condic <mcondic.auntie.spam@acm.org> wrote:
>
> > I would think that a reasonable implementation of Ada for realtime
> > systems would want to insure that the precision had some relationship
> > to the accuracy of the clock available. Obviously, for
> Do you mean "accuracy" or "frequency"?

O.K. Pick nits. :-) I meant "frequency" but this is in a way related to
"accuracy". If my micrometer is marked off in thousanths of an inch, it does
me no good to try to measure ten-thousanths of an inch, so in manufacturing
parts, I can't be any more accurate than to a thousanth of an inch. My
micrometer may have been bounced off the milling machine a few times too many
and may actually not be "accurate" in measuring a 1" dimension.

>
> ...
> > be changed for the language. But stating, for example, that the
> > precision of a time representation can go down to atto-seconds can
> > easily mislead one to believe that the measurement of time is going to
> > be something close to that precision.
>
> This gets back around to the issue we were discussing a couple of weeks
> ago. If the language requires units of seconds, but the system's clock
> used some incompatable system like Hz (eg: 60 Hz, which can't be
> represented exactly in terms of fixed-point seconds), then you (or at
> least *I*) would actually prefer a much higher precision, so that your
> error in representation isn't so great when you start to do math with it.

Well, you do want some precision beyond the smallest unit of the actual clock
time if you have this sort of situation. But most of the clocks I've seen are
some version of a scaled integer, thus allowing Duration'Small to be whatever
it wants to be as long as the LSB is under 20mSec. Am I incorrect in this?

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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Robert Dewar]

In article <3A72DC5E.4C1CE092@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:

> I can't be any more accurate than to a thousanth of an inch.
> My micrometer may have been bounced off the milling machine a
> few times too many and may actually not be "accurate" in
> measuring a 1" dimension.

You are assuming that type Duration is solely for use by the
delay statement or for use in conjunction with values read
from the clock (these may of course have totally unrelated
low order accuracy), but this is just not true.

It would clearly be MUCH less useful if Duration was target
dependent and had only a precision corresponding to the delay
accuracy. No one could really sensibly prefer this!


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Ted Dennison]

In article <3A72DC5E.4C1CE092@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:

> O.K. Pick nits. :-) I meant "frequency" but this is in a way related
> to "accuracy". If my micrometer is marked off in thousanths of an
> inch, it does me no good to try to measure ten-thousanths of an inch,
> so in manufacturing parts, I can't be any more accurate than to a
> thousanth of an inch. My micrometer may have been bounced off the
> milling machine a few times too many and may actually not be
> "accurate" in measuring a 1" dimension.

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

> Well, you do want some precision beyond the smallest unit of the
> actual clock time if you have this sort of situation. But most of the
> clocks I've seen are some version of a scaled integer, thus allowing
> Duration'Small to be whatever it wants to be as long as the LSB is
> under 20mSec. Am I incorrect in this?

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.

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
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!

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Buz Cory]

On 1/29/01, 1:40:29 PM, Marin David Condic <mcondic.auntie.spam@acm.org> 
wrote regarding Re: Duration vs. Ada.Real_Time:

[snip]

> BTW: I've asked before when I was dealing with that same situation
> - two machines that want to operate in lockstep.

You failed to say to what degree of precision. Am assuming below that
a discrepancy on the order of 10ms is OK.

> 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"

You mean you had a periodic interrupt and weren't counting?

If you were counting, then there was your clock. It may have had to
be set externally to sync w/ external time, but it was still there.

One would assume that the 1.024 ms interrupt came from a HW device
counting 1MHz pulses. If that register was readable somehow, now you
had a time resolution of 1µs.

Naturally, if the 1MHz signals are separately generated for each
box, there will be some drift (though I wouldn't expect a lot). One
way to solve this would be to provide the base tick externally.

> - and some hardware signaling 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.

Assuming that since the boxen had to be in lock-step, they were
networked in some way, there is definitely a software solution

Assuming an ethernet LAN, synching w/ an error < 10ms is claimed by
the author. (Maybe an order of magnitude worse for a WAN.)

The docs that came w/ xntpd may be read at:
    "http://BuzCo.PenguinPowered.com/imports/net/time/".
Unfortunately, the PenguinPowered.com nameserver is down as I write
this :-< (Between ISP problems and nameserver problems I seem to get
some 80% availability).

You can find basic material on this at "http://www.ntp.org/".
The software may be downloaded (documented in *_great_* detail) from
    "ftp://ftp.udel.edu/pub/ntp/".

The algorithms, the software, and the related RFCs (referenced in
the docs) are all the work of one Dr. David Mills, who seems to be
The Expert on network time synchronization. I know I could not
follow the details, I just use the software.

BTW, using the supplied software assumes that you are running some
variant of Un*x; the provided daemon runs in user-space but can talk
to the kernel software that maintains time-of-day.

The code is in "C" and gives some warning messages when compiled w/
gcc.

Hope this helps,
== Buz :)
--
Buz Cory of Buzco Systems -- New York NY USA 
http://BuzCo.PenguinPowered.com
<netadm@BuzCo.PenguinPowered.com> (Buz as Net Admin)
write to <helpdesk@BuzCo.PenguinPowered.com> for FREE help with:
    Installing/Configuring Linux
    Getting started with the Ada Programming Language.
Replacing DOS/MS-Win with Linux is like replacing a Fokker with an 
F14.
Programmer? Bugs got you down? Ada is the answer.

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

Actually, the problem was a lot more specialized than what you seem to be
gathering from my post. Basically, it was two separate, identical computers
running identical software with independent 1.024mS interrupts. (No common
time source or this would have been a source for common-mode failure)

Given the presence of watchdog timers in both boxes that had to be stroked
on specific cycles and the need for each computer to be operating on
identical sensor input, you wanted to have them sync'ed on the same cycle
and starting each cycle with a high degree of precision. (I believe we
settled on about 50uS as a jitter amount, so that was roughly the tolerance
of the sync.)

We had primitive communications between the two CPU's - a Manchester data
link and a couple of discretes.

We achieved sync by basically having the two machines look for each other on
the discretes and one machine taking small delays until they both arrived at
the same cycle. From there, we pulled a few other tricks involving delays
until the machines were in fine sync. (BTW, the same basic problem happens
with frequency-hopping radios where you don't have a common time source or
you can't get the time source until you achieve coarse sync.)

Basically, we came up with a solution that worked, but I could never get
over the feeling that some academic type had probably written a book or a
paper discussing various methods of doing this which might have shed some
light on better ideas.

Network time synchronization is far more heavily studied, but doesn't have
quite the same set of problems.

MDC

Buz Cory wrote:

> On 1/29/01, 1:40:29 PM, Marin David Condic <mcondic.auntie.spam@acm.org>
> wrote regarding Re: Duration vs. Ada.Real_Time:
>
> [snip]
>
> > BTW: I've asked before when I was dealing with that same situation
> > - two machines that want to operate in lockstep.
>
> You failed to say to what degree of precision. Am assuming below that
> a discrepancy on the order of 10ms is OK.
>
> > 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"
>
> You mean you had a periodic interrupt and weren't counting?
>
> If you were counting, then there was your clock. It may have had to
> be set externally to sync w/ external time, but it was still there.
>
> One would assume that the 1.024 ms interrupt came from a HW device
> counting 1MHz pulses. If that register was readable somehow, now you
> had a time resolution of 1�s.
>
> Naturally, if the 1MHz signals are separately generated for each
> box, there will be some drift (though I wouldn't expect a lot). One
> way to solve this would be to provide the base tick externally.
>
> > - and some hardware signaling 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.
>
> Assuming that since the boxen had to be in lock-step, they were
> networked in some way, there is definitely a software solution
>
> Assuming an ethernet LAN, synching w/ an error < 10ms is claimed by
> the author. (Maybe an order of magnitude worse for a WAN.)
>
> The docs that came w/ xntpd may be read at:
>     "http://BuzCo.PenguinPowered.com/imports/net/time/".
> Unfortunately, the PenguinPowered.com nameserver is down as I write
> this :-< (Between ISP problems and nameserver problems I seem to get
> some 80% availability).
>
> You can find basic material on this at "http://www.ntp.org/".
> The software may be downloaded (documented in *_great_* detail) from
>     "ftp://ftp.udel.edu/pub/ntp/".
>
> The algorithms, the software, and the related RFCs (referenced in
> the docs) are all the work of one Dr. David Mills, who seems to be
> The Expert on network time synchronization. I know I could not
> follow the details, I just use the software.
>
> BTW, using the supplied software assumes that you are running some
> variant of Un*x; the provided daemon runs in user-space but can talk
> to the kernel software that maintains time-of-day.
>
> The code is in "C" and gives some warning messages when compiled w/
> gcc.
>
> Hope this helps,
> == Buz :)
> --
> Buz Cory of Buzco Systems -- New York NY USA
> http://BuzCo.PenguinPowered.com
> <netadm@BuzCo.PenguinPowered.com> (Buz as Net Admin)
> write to <helpdesk@BuzCo.PenguinPowered.com> for FREE help with:
>     Installing/Configuring Linux
>     Getting started with the Ada Programming Language.
> Replacing DOS/MS-Win with Linux is like replacing a Fokker with an
> F14.
> Programmer? Bugs got you down? Ada is the answer.

--
======================================================================
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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Steve Whalen]

You think you had problems... did you read the NSA mongraph on the
WWII SIGSALY system? 
 
 http://www.nsa.gov/wwii/papers/start_of_digital_revolution.htm

In glancing at it again, I don't think their synchronization solution
would have helped you because they primarily relied on an external 
time source, but maybe some of their other tricks for maintaining
synchronization might be adaptable to your situation (somehow 
translating hardware / mechanical / analog into Ada!).

Steve

Marin David Condic <mcondic.auntie.spam@acm.org> wrote in
<3A82BC7B.8EF005AB@acm.org>: 

>Actually, the problem was a lot more specialized than what you seem to
>be gathering from my post. Basically, it was two separate, identical
>computers running identical software with independent 1.024mS
>interrupts. (No common time source or this would have been a source for
>common-mode failure) 
>
>Given the presence of watchdog timers in both boxes that had to be
>stroked on specific cycles and the need for each computer to be
>operating on identical sensor input, you wanted to have them sync'ed on
>the same cycle and starting each cycle with a high degree of precision.
>(I believe we settled on about 50uS as a jitter amount, so that was
>roughly the tolerance of the sync.)
>
>We had primitive communications between the two CPU's - a Manchester
>data link and a couple of discretes.
>
>We achieved sync by basically having the two machines look for each
>other on the discretes and one machine taking small delays until they
>both arrived at the same cycle. From there, we pulled a few other tricks
>involving delays until the machines were in fine sync. (BTW, the same
>basic problem happens with frequency-hopping radios where you don't have
>a common time source or you can't get the time source until you achieve
>coarse sync.) 
>
>Basically, we came up with a solution that worked, but I could never get
>over the feeling that some academic type had probably written a book or
>a paper discussing various methods of doing this which might have shed
>some light on better ideas.
>
>MDC

-- 
------------------------------------------------------------
---   Steve Whalen                  swhalen@micron.net   ---
------------------------------------------------------------

Re: Duration vs. Ada.Real_Time

[Robert Dewar]

In article <3A71E4F6.6D7015AD@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:

> I would think that a reasonable implementation of Ada for
> realtime systems would want to insure that the precision had
> some relationship to the accuracy of the clock available.

Why do you think that?

The RM contains no encouragement for this thought!

Duration is used for other things besides the delay statement.

And also, programs do various calculations with Duration, if
there is more precision, these calculations are more accurate.


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

Robert Dewar wrote:

> In article <3A71E4F6.6D7015AD@acm.org>,
>   Marin David Condic <mcondic.auntie.spam@acm.org> wrote:
>
> > I would think that a reasonable implementation of Ada for
> > realtime systems would want to insure that the precision had
> > some relationship to the accuracy of the clock available.
>
> Why do you think that?
>

Because as a real-time programmer, I feel like it. :-) Just because it
would be reasonably useful to me if Duration were a scaled integer that
just so happened to match exactly the scaled integer representation of
the time source I had available to me.

>
> The RM contains no encouragement for this thought!
>

And that matters to me why? Just because the ARM didn't make a
pronouncement on it doesn't stop it from being useful to me. And if you
are selling me a product and I express my desires for what that product
should do, and you appeal to the ARM to tell me my desires are not
reasonable, would you be surprised when I pick a different compiler?

>
> Duration is used for other things besides the delay statement.
>

O.K. And I suppose I could probably use Duration for a thousand things
that had nothing whatsoever to do with time. If Duration were the same
size as Long_Long_Float, I might use it to do matrix multiplication -
just because it was there and handy.

I don't think that would change my position on why I'd like the type to
correspond (as much as is possible) to whatever time source I have
available.


>
> And also, programs do various calculations with Duration, if
> there is more precision, these calculations are more accurate.
>

That may very well be true depending on the implementation. I don't
think that changes anything for me. I'd bet a nickle that if you looked
at all the math ops performed on anything of type Duration, you'd find
that most of them were adds, the next level would be subtracts and all
other math ops would fall so far into the weeds as to be of little
concern. Yes, I know you can come up with cases where this may not hold.
In practice, I just don't think it would come up that often.

If Duration is a fixed point type with a delta that lines up to the LSB
of my time source (and I have never seen a hardware source that gave me
time as a floating point number - maybe they exist - I've never seen
one.) then it would seem to me that I am computing at the resolution of
my ability to measure. Given that (for most real time systems) I'm 99%
of the time going to be adding and subtracting, I don't think extra low
order bits are going to help me out here much. If I *really* needed to
do some sort of complex math with a bunch of Durations where I thought
that rounding errors might accumulate & become a problem, I guess I'd
convert them to a Long_Long_Float (or Long_Long_Long_Float? :-), do the
math, then convert back. I find that doing any sort of complex math with
scaled integers is a good way to inject errors into the code anyway.
Maybe you've got to do that because of hardware, but it isn't what I'd
prefer.

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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Stephen Leake]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <3A71E4F6.6D7015AD@acm.org>,
>   Marin David Condic <mcondic.auntie.spam@acm.org> wrote:
> 
> > I would think that a reasonable implementation of Ada for
> > realtime systems would want to insure that the precision had
> > some relationship to the accuracy of the clock available.
> 
> Why do you think that?
> 
> The RM contains no encouragement for this thought!
> 
> Duration is used for other things besides the delay statement.

Perhaps it would be more appropriate for Marin to request that type
Ada.Real_Time.Time_Span (LRM appendix D) match the hardware clock;
that is more clearly intended to be a "hard real-time" clock type.

> And also, programs do various calculations with Duration, if there
> is more precision, these calculations are more accurate.

I agree with Marin here; convert to a type that you know or control
the precision of to do computations.

-- 
-- Stephe

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

Stephen Leake wrote:

> Perhaps it would be more appropriate for Marin to request that type
> Ada.Real_Time.Time_Span (LRM appendix D) match the hardware clock;
> that is more clearly intended to be a "hard real-time" clock type.
>

Oh, I'm not really fussy about how you get there. That might work
reasonably well. And I certainly don't insist that *every*
implementation of Ada go off and do it my way. My point is that when one
is working with an embedded compiler for a specific target that has a
real time clock, one just kind of expects Duration to have some
relationship to that clock. If you do delays, you kind of expect to be
able to get a delay approximately as good as the resolution of the clock
- no more - no less.

An analogy would be, for example, someone implementing the type
Character as a 32 bit word. (Don't know if this is *legal*, but suppose
that it was?) Yes, a 32 bit word will hold a single ASCII character just
fine and provided the compiler is consistent in this, it will mostly be
invisible to the programmer. But if someone declares an object of type
Character (or aray of them) one rather expects to allocate and use a
single byte. Anything else would be regarded as kind of silly. For most
applications, it may not matter, but for embedded work, it could be
quite important because you are so close to the hardware.


>
> > And also, programs do various calculations with Duration, if there
> > is more precision, these calculations are more accurate.
>
> I agree with Marin here; convert to a type that you know or control
> the precision of to do computations.

Thanks. :-)

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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Ted Dennison]

In article <uk87d9kjh.fsf@gsfc.nasa.gov>,
  Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:

> Perhaps it would be more appropriate for Marin to request that type
> Ada.Real_Time.Time_Span (LRM appendix D) match the hardware clock;
> that is more clearly intended to be a "hard real-time" clock type.

OK. I've tried to just say "its not that simple". Since no one seems to
be accepting that, let's look at this suggestion in detail. Let's
postulate a PC system, since that's the most common one in use.

The PC system has 3 built-in timing methods. The first is the
"Real-Time" clock, which is usually used to drive OS scheduling
operations. This is essentially the 8253 timer chip, which divides
4.77272MHz signals from the processor (I'm not sure if this is standard,
or varies depending on the processor or bus speed. I'm also not sure if
its exact, or an approxmiation) into some convienent number of RTC
interrupts (like by 65536 to produce interrupts at 18.20648Hz).
However, it is possible for software to change this amount. Thus, if an
Ada compiler were to use "the units of the clock" for this clock, it
would have to use either some huge number in units of 4.77272 x 10^^-6
(or whatever the particular system uses for its base), or it would have
to somehow dynamcily pick the units that the RTC happens to be spewing
out at the moment (and be ready to change if software changes it).
However, the OS most likely uses its own approximation for these units,
so the compiler would have to approxmiate whenever passing control to
the OS for actual scheduling.

There is also a "time of day" clock that just keeps a counter in memory.
For most Ada compilers this clock will only be accessed through OS
system calls. Whatever units the OS uses would be OK here.

There is also a high-frequency timer. This also just keeps a counter in
memory. However in this case it is the CPU doing it, and the counter
increments by one each time the CPU cycles. Thus its rate is dependent
on the clock rate of the CPU. It is possible to set up interrupts when
the counter reaches a (software-set) value. Thus this could be used, but
the Ada compiler would then have to pick units that match the processor
clock speed (which would probably not match any of the above).

Short answer: its not that simple.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

You are right. It is "not that simple" - certainly for a number of possible
targets. I think my only point here was that there are some hardware
configurations where you *do* have a time source that *could* be reflected
by Duration and when that is the case, that's probably what you want to do.

In your example you have three possible time sources. Which would you pick
for dealing with Duration? Which would you pick for Ada.Real_Time.Time_Span?
Maybe for this particular hardware configuration you make Duration have some
arbitrarily large precision and move on. Maybe where you have a gate array
or some on-board register or some similar configuration wherein you can
interrogate the time source & get a scaled integer with an LSB of - say -
1uSec, then Duration ought to reflect this.

I'm not saying all Ada compilers everywhere should do this for every target
- just where it makes some sense because of what the hardware or OS provides
you. It might be possible to make it user configurable (select time source
and select precision, then rebuild so the compiler gives you what you want.)
For embedded and realtime applications, I think this is a useful feature.

MDC

Ted Dennison wrote:

> In article <uk87d9kjh.fsf@gsfc.nasa.gov>,
>   Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
>
> > Perhaps it would be more appropriate for Marin to request that type
> > Ada.Real_Time.Time_Span (LRM appendix D) match the hardware clock;
> > that is more clearly intended to be a "hard real-time" clock type.
>
> OK. I've tried to just say "its not that simple". Since no one seems to
> be accepting that, let's look at this suggestion in detail. Let's
> postulate a PC system, since that's the most common one in use.
>
> The PC system has 3 built-in timing methods. The first is the
> "Real-Time" clock, which is usually used to drive OS scheduling
> operations. This is essentially the 8253 timer chip, which divides
> 4.77272MHz signals from the processor (I'm not sure if this is standard,
> or varies depending on the processor or bus speed. I'm also not sure if
> its exact, or an approxmiation) into some convienent number of RTC
> interrupts (like by 65536 to produce interrupts at 18.20648Hz).
> However, it is possible for software to change this amount. Thus, if an
> Ada compiler were to use "the units of the clock" for this clock, it
> would have to use either some huge number in units of 4.77272 x 10^^-6
> (or whatever the particular system uses for its base), or it would have
> to somehow dynamcily pick the units that the RTC happens to be spewing
> out at the moment (and be ready to change if software changes it).
> However, the OS most likely uses its own approximation for these units,
> so the compiler would have to approxmiate whenever passing control to
> the OS for actual scheduling.
>
> There is also a "time of day" clock that just keeps a counter in memory.
> For most Ada compilers this clock will only be accessed through OS
> system calls. Whatever units the OS uses would be OK here.
>
> There is also a high-frequency timer. This also just keeps a counter in
> memory. However in this case it is the CPU doing it, and the counter
> increments by one each time the CPU cycles. Thus its rate is dependent
> on the clock rate of the CPU. It is possible to set up interrupts when
> the counter reaches a (software-set) value. Thus this could be used, but
> the Ada compiler would then have to pick units that match the processor
> clock speed (which would probably not match any of the above).
>
> Short answer: its not that simple.
>
> --
> T.E.D.
>
> http://www.telepath.com/~dennison/Ted/TED.html
>
> Sent via Deja.com
> http://www.deja.com/

--
======================================================================
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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Ted Dennison]

In article <3A786497.1C791722@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:

> In your example you have three possible time sources. Which would you
> pick for dealing with Duration? Which would you pick for
> Ada.Real_Time.Time_Span?

For a PC, if I were making TEDAda, I'd probably want to match duration
with the units the OS uses for its time of day primitives (which are
possibly based on source 2) or the Ada minimum requirements, whichever
is higher-res. For Ada.Real_Time.Time, It'd be nice to use units of
ticks on the high-frequency clock (time source 3), as that will give me
the most possible resolution (which is critical for being able to
accurately measure elapsed time for small tasks). For
Ada.Real_Time.Time_Span, it would probably be best to use the same
units, as  I'd want to be able to use Real_Time.Time_Span in
calculations with Real_Time.Time without loosing accuracy. That means
any use of "delay" or "delay until" is going require a conversion from
one of those other time sources into the OS's units for its thread timed
rescueduling primitives (perhaps based on source 1). However, that is
often in RTC "ticks", so a conversion would have been nessecary anyway.

I know our Ada vendor (GreenHills) chose to use microseconds as its
units for Ada.Real_Time.Time. I believe they made that decision because
support for the high-res timer is a kernel-configurable item (not always
available), and because they use the same compiler codebase on multiple
architectures under the same OS. So it was a good decision for them. But
it has the unfortunate effect that any use of the high-res timer has to
be done via direct OS calls.


> I'm not saying all Ada compilers everywhere should do this for every
> target - just where it makes some sense because of what the hardware
> or OS provides you. It might be possible to make it user configurable

Is there some RTC hardware out there that uses seconds instead of Hz as
its units? If so, and if its OS rescheduling primitive kept the same
units, then yes, the Ada vendor for that platform should also use those
same units.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[tmoran]

>I know our Ada vendor (GreenHills) chose to use microseconds as its
>units for Ada.Real_Time.Time.  ...
>it has the unfortunate effect that any use of the high-res timer has to
>be done via direct OS calls.
  Can you replace the body of Ada.Real_Time that they supply with one
of your own?

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

Ted Dennison wrote:

> Is there some RTC hardware out there that uses seconds instead of Hz as
> its units? If so, and if its OS rescheduling primitive kept the same
> units, then yes, the Ada vendor for that platform should also use those
> same units.

Well, even if its hz, that doesn't mean Duration'Small can't have that
value. Let's say that the clock goes at 1000hz - Each tick is 1/1000 of a
second, correct? (1hz = 1 cycle/sec - unless senility is setting in? :-)
Duration'Small is 0.001. If the clock is at 1024hz then each tick is 1/1024
of a second. Duration'Small is 0.0009765625. (somewhere you have a
declaration: "for Duration'Small use 0.0009765625 ;" - change the target? -
change this statement in the compiler and off you go.)

All you're saying is that the LSB of Duration has some quantum value which
is measured in units of seconds. As long as this falls under 0.020, its
within the requirements of the Ada standard and Duration coincides nicely
with your available clock.

Now if your clock gives you an IEEE 80 bit floating point value, the story
has to change. I've just never seen one of those.

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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Ted Dennison]

In article <3A7887E2.49CF12C5@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:

> Well, even if its hz, that doesn't mean Duration'Small can't have that
> value. Let's say that the clock goes at 1000hz - Each tick is 1/1000
> of a second, correct? (1hz = 1 cycle/sec - unless senility is setting
> in? :-)

Our simulation uses clocks of 60Hz and 240Hz. The default for vxWorks is
60Hz. Try those (or any other Hz value divisible by 3) on for size. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Simon Wright]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

"Atle R�stad" <aer@edh.ericsson.se> writes:

> Hi
> 
> I have some code that has a max of 30 milliseconds to process, and need to
> measure if this is possible. But the requirement for Duration is that
> Duration'Small must be less then 20 milliseconds, and
> Ada.Real_Time.Time_Unit must be less then 20 microseconds.
[...]
> I will run the program on an Solaris 8. How will this affect my time
> measuring? What resolution can I expect?

(1) On Solaris (>=2.6 or so, I think) the default operating system
    tick is 10 mS.

(2) GNAT uses nanosleep() to implement delay (pretty sure of this).

(3) nanosleep() sleeps for *at least* the time you specify, rounded up
    to an integral number of ticks.

(4) So, if you "delay 0.000_001;", you'll delay for at least 10 mS and
    up to 20 mS.

However, you can change the OS tick to 1 mS by writing

  set hires_tick 1

in /etc/system (I may have the exact grammar wrong, mail me at work
for the details). This will give you a maximum repetition frequency of
500 Hz.

NB, that 1 is a boolean meaning 'true', _not_ the number of milliseconds!

Running as root gives you real-time dispatching but doesn't change the
behaviour of nanosleep().

Linux is similar, though there's no easy way to change the tick rate
(you can edit /usr/include/asm/param.h, or figure a way to redefine
HZ, and rebuild the kernel; worked fine for us, but YMMV, though,
since the library won't match). And don't try delays < 2 mS as root,
they're executed as busy loops.

-- 
Simon Wright                       Work Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                        Voice: +44(0)23-9270-1778
Integrated Systems Division                     FAX: +44(0)23-9270-1800

Re: Duration vs. Ada.Real_Time

[Robert Dewar]

In article <x7vd7d7bhgt.fsf@smaug.pushface.org>,
  Simon Wright <simon@pushface.org> wrote:

> However, you can change the OS tick to 1 mS by writing
>
>   set hires_tick 1
>
> in /etc/system

Do you suppose that those who favor Duration'Small matching
the tick would want this OS command to magically change the
value of this static constant retroactively? :-)



Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Marin David Condic]

Robert Dewar wrote:

> IDo you suppose that those who favor Duration'Small matching
> the tick would want this OS command to magically change the
> value of this static constant retroactively? :-)

As I said somewhere back in this thread, I'd only advocate it where it
was practical and useful. When you're going through an OS, you have to
make allowances for what the OS is doing for you. And again, it is only
important for realtime and/or embedded work where timing of things is
pretty critical. Someone selling/using a platform application compiler
that is being used for payroll processing is probably only going to use
delays of a granularity of a second or so just for user interaction
things. They don't really care if its off by a few microseconds. Do
whatever you like.

What I *might* advocate here is that the 'Small be set to something
representing the smallest possible unit that the OS will handle - or
possibly just a little more accuracy than that to allow for rounding. I
just think it would be misleading if a compiler says that 'Small is
going to be 0.000_000_000_000_000_001 and this has no relationship
whatsoever to what the actual hardware/OS is really capable of.

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]
======================================================================

Re: Duration vs. Ada.Real_Time

[Robert Dewar]

In article <3A782A43.680425AE@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:
> I just think it would be misleading if a compiler says that
> 'Small is going to be 0.000_000_000_000_000_001 and this has
> no relationship whatsoever to what the actual hardware/OS is
> really capable of.

This would only mislead someone who thinks there should be a
relationship between the two. Since the RM does not give any
hint that such a relationship is required or desirable, no one
should be under this impression, and thus no one should be
misled who clearly understands the language.


Sent via Deja.com
http://www.deja.com/

Re: Duration vs. Ada.Real_Time

[Christoph Grein]

> (1) On Solaris (>=2.6 or so, I think) the default operating system
>    tick is 10 mS.

What do you mean by measuring times in Millisiemens (mS)?

	10 mS = 10E-3 S = 10e-3 / Ohm

which definitely has not the unit of time.

Please see the new thread "Wrong SI unit specification" ;>)

Re: Duration vs. Ada.Real_Time

[Simon Wright]

Christoph Grein <christoph.grein@eurocopter.de> writes:

> > (1) On Solaris (>=2.6 or so, I think) the default operating system
> >    tick is 10 mS.
> 
> What do you mean by measuring times in Millisiemens (mS)?
> 
> 	10 mS = 10E-3 S = 10e-3 / Ohm
> 
> which definitely has not the unit of time.

::aaaaargh::

got me there :-(

-- 
Simon Wright                       Work Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                        Voice: +44(0)23-9270-1778
Integrated Systems Division                     FAX: +44(0)23-9270-1800
Ex-physicist                             Paid-up member of Pedants`R`Us