Re: Problems with Alsys 386 V5.1.1 Compiler

Re: Problems with Alsys 386 V5.1.1 Compiler

[Sam Houston]

In article AA25446@cs.utexas.edu, CZinsmeyer%TSS%SwRI05@D26VS046A.CCF.SwRI.EDU 
() writes:
>I'm developing an application for the U.S. Air Force

        ... Stuff Deleted...

>                     After some period of time, usually twenty minutes or 
>so, the system begins to slow down.  The longer the system runs the slower 
>things get.  

        ... More Stuff Deleted


I remember hearing of a similar problem in the development of the
Patriot Missle system.  It had something to do with floating point
precision and the clock.  I don't remeber the details, but you
might want to see if you can find the information.  Hope this helps.

Sam Houston
Disclaimers:  Not _THE_ Sam Houston, just _a_ Sam Houston
              Opinions may not even be my own, much less those
              of my company.

Re: Problems with Alsys 386 V5.1.1 Compiler

[cis.ohio-state.edu!math.ohio-state.edu!sdd.hp.com!col.hp.com!csn!news.sin]

In article 51b@issi-gw.issi.com, houston@issi.com (Sam Houston) writes:
> In article AA25446@cs.utexas.edu, CZinsmeyer%TSS%SwRI05@D26VS046A.CCF.SwRI.ED
U () writes:
> >I'm developing an application for the U.S. Air Force
> >                     After some period of time, usually twenty minutes or 
> >so, the system begins to slow down.  The longer the system runs the slower 
> >things get.  
> 
> I remember hearing of a similar problem in the development of the
> Patriot Missle system.  It had something to do with floating point
> precision and the clock.  I don't remeber the details, but you
> might want to see if you can find the information.

I thought that the Patriot Missile system got *less accurate* as time went by, 
since in some calculation they were dividing through by the elapsed time using 
fixed point arithmetic. As time went by, the elapsed time counter got larger, a
nd so more and more precision was lost on the divide.

That's the version I heard... anyone really know?

I really don't think it is in any way related to the Alsys bug.

> Sam Houston

Mat


---
| Mathew Lodge               | "There's nothing intellectual about wandering |
| lodge@ferndown.ate.slb.com |  around Italy in a big shirt trying to get    |
| Schlumberger Technologies, |  laid" -- Blackadder on the romantic poets    |
| ATE division, Ferndown, UK | I speak for me, not Schlumberger Technologies |

Re: Problems with Alsys 386 V5.1.1 Compiler

[Robert Kitzberger]

houston@issi.com (Sam Houston) writes:

>In article AA25446@cs.utexas.edu, CZinsmeyer%TSS%SwRI05@D26VS046A.CCF.SwRI.EDU
 () writes:
>>                     After some period of time, usually twenty minutes or 
>>so, the system begins to slow down.  The longer the system runs the slower 
>>things get.  
>
>I remember hearing of a similar problem in the development of the
>Patriot Missle system.  It had something to do with floating point
>precision and the clock.  

The problem with the Patriot had to do with loss of accuracy in
converting from integers (clock ticks) to real number representations
of time, which were used in targetting algorithms.  For small
integers, the conversion inaccuracies were small, but for large
integers (i.e. lots of clock ticks...) the inaccuracies were
sufficient to cause the Patriot to miss its mark.  From a GAO report
entitled "PATRIOT MISSILE DEFENSE: Software Problem Led to System
Failure at Dhahran, Saudi Arabia":

	The range gate's prediction of where the Scud will next
	appear is a function of the Scud's known velocity and the time
	of the last radar detection.  Velocity is a real number that
	can be expressed as a whole number and a decimal (e.g.
	3750.2563...miles per hour).  Time is kept continuously by the
	system's internal clock in tenths of seconds but is expressed
	as an integer or whole number (e.g., 32, 33, 34...).  The
	longer the system has been running, the larger the number
	representing time.  To predict where the Scud will next
	appear, both time and velocity must be expressed as real
	numbers.  Because of the way the Patriot computer performs its
	calculations and the fact that its registers are only 24 bits
	long, the conversion of time from an integer to a real number
	cannot be any more precise than 24 bits.  This conversion
	results in a loss of precision causing a less accurate time
	calculation.  The effect of this inaccuracy on the range
	gate's calculation is directly proportional to the target's
	velocity and the length of time the system has been running.


	Report is GAO/IMTEC-92-26, call (202)275-6241 for your copy.

If the poster is actually missing clock ticks, then I suspect
that interrupts are being disabled for longer than a clock tick
(not the problem that the Patriot folks had).  This could happen for
several reasons, chiefly (a) user code disabling the interrupts for too
long a time, or (b) pathological nondeterminism in the kernel.

        .Bob.


--
Bob Kitzberger                          Internet:   rlk@rational.com
Rational, Grass Valley, CA              CompuServe: 70743,1550