TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Daniel Wengelin <[log in to unmask]>
Reply To:
Daniel Wengelin <[log in to unmask]>
Date:
Mon, 9 Dec 1996 22:52:59 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (73 lines)
Dear friends,
a very interesting thread this is, and quite confusing. I don't even
recognize the problem!

I'm working on a system (Ada83, but anyhow), running AIX and OCS Ada6000.
The OS defines the Universal Time Coordinate (UTC) which is basically what
I understand GNAT's clock is based on. But, UTC is not the clock the user
would see, and any customer requirements to change the clock with one hour
or so should not interfere with UTC. If UTC has to be changed one hour
there is something wrong with the system design?! The drift of a
workstation UTC compared to a really good clock, like a GPS, should be in
the order of magnitude of my wrist watch, say a second per day. To adjust
UTC one hour would compensate for more than 100 yrs of continous operation.
With an averaging protocol for a network of computers the continous drift
is basically eliminated.

So, flame me if I'm wrong, but I think that there is an architecture level
misconception if UTC has to be changed more than the drift of the hardware
clock, something that is easily accomodated within the GNAT implementation.


Professor Dewar is right. GNAT does what is right even for a system with
millisecond accuracy and zero drift requirements.


Cheers, Daniel


SNIP------ from Stephen Doiel

>In my company we deliver systems to customers that typically run
>continuously for periods that exceed a year (sometimes several).  In
>practice, we have found that it is "routine" for an
>end user to make adjustments.
>
>We used to use the regular system clock for timing events.  We found
>that when a customer
>adjusted the time, we had processes that were supposed to pend for
>100 msec, that suddenly pended for 360100 msec (an hour and 100 msec)
>because of a time change.
>
>We modified our system to use two clocks, one that is rate monotonic,
>at it has resolved this
>problem.
>
>Ada 95 provides 2 clock facilities.  Calendar and Real_Time.
>The choice of implementation in GNAT on UNIX would require us to
>construct our own time facility to give us what I would consider to
>be a truely "rate monotonic" clock.
>
>I believe this is contrary to the spirit of having separate Calendar
>and Real_Time packages
>in Ada.
>
>IMHO
>Steve Doiel
>

Daniel Wengelin <[log in to unmask]>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia

mQCPAzFZr9MAAAEEAK8Nbxb25/RIZs2Cx2KXrY1piBlhC6qssZ+AW8E7GVYPsBrD
76XWRCoeh/+8bcfLW7B4GvN0OpRhdQPOqeON7KySaV+4mZ8FAgxMqRjRzJu9/4ps
0z9CTagQhPXhLINuBFNuggnj/LuFSegN1e6q58B+V8zn8ClKCBCNjqkHDZzRABEB
AAG0JURhbmllbCBXZW5nZWxpbiA8d2VuZ2VsaW5AYWxnb25ldC5zZT6JAJUDBRAx
Wa/VEI2OqQcNnNEBAZw9A/9bNofi9DtTY1IQjX3qVOkZHXFR4YE2WFsmDe5VeNpc
9acPqSU8tzbsJgVGZ4Y2Fv1czEIlLC1BrOjCweH16mhtt9lSESxdt3svT04MEVxR
Qczk6I1WMOGZhpgds12QULAxfvoKkKvR/3sCuMYfnoEIm5k0JKTs7zTJxoCnlZKJ
KA==
=ZKqg
-----END PGP PUBLIC KEY BLOCK-----

ATOM RSS1 RSS2