TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Daniel Wengelin <[log in to unmask]>
Date: Mon, 9 Dec 1996 22:52:59 +0100
X-To: Stephen Doiel <[log in to unmask]>
Reply-To: Daniel Wengelin <[log in to unmask]>
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
>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.
>Steve Doiel

Daniel Wengelin <[log in to unmask]>
Version: 2.6.3ia