comp.lang.ada
 help / color / mirror / Atom feed
* CPU & Memory opinions wanted...
@ 1997-01-21  0:00 Ron Thompson
  1997-01-22  0:00 ` Michael F Brenner
  0 siblings, 1 reply; 2+ messages in thread
From: Ron Thompson @ 1997-01-21  0:00 UTC (permalink / raw)




The few, the brave, the Ada programmers.  You guys would
understand, so I'll ask for some opinions if you don't
mind giving them up:

Two MVME 177 Cards running in a box, Lynx is OS.  Card A
knows not of Card B.  They share no memory, share no work.
Apps on A stay on A, same on B.  We require x percent of
CPU overhead remain as reserve, and x percent memory remain
as reserve.  Sales pitch is that we add up CPU usage, add
up memory reserves, divide by 2, amazingly enough, we get
adequate both.  Card A at 14meg of 16 used, we need 25%.
Card B has loads, 10meg left over.  Add them up/2, you get
a pretty good figure.  Forget for a minute that the mem on
one card is useless to the other...

Any opinions on this method of calculating chip/memory
overhead numbers???  email me if you have to, and thanks
to the few and the brave.

rct

The opinons above are mine and mine alone.





^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: CPU & Memory opinions wanted...
  1997-01-21  0:00 CPU & Memory opinions wanted Ron Thompson
@ 1997-01-22  0:00 ` Michael F Brenner
  0 siblings, 0 replies; 2+ messages in thread
From: Michael F Brenner @ 1997-01-22  0:00 UTC (permalink / raw)



Mike Brenner of MITRE has the following opinion (the following 
sentence must be quoted in its entirety):
Adding the reserves up and dividing by two is mathematically valid under
two circumstances: (1) perfect independent sharing of work and resources
with no overhead; and (2) logically frivolous reserve requirements;
since you did not say you had any realtime deadlines to meet, we 
presume there are none, so the reserve requirements may be frivolous,
and your procedure  might work; however, it increases the risk
substantially that you are developing on an old, slow, small-RAM
system that will thus be more expensive to maintain (enhance) later.

When a reserve requirement is arbitrary it is more common to ask for
a waiver, so the customer knows they are getting a cheaper system,
a working system, a system with a higher risk that last minute error 
corrections will not fit, and a system for which they will have to budget
hardware additions in order to add substantially to the software. By
being up front about the pluses and minuses of not having enough reserve
on CPU A and plenty of reserve on CPU B, a more correct risk analysis
is applied than averaging numbers that are not related. If final
system testing results in a 15% increase in software size on CPU A,
it is the 14% reserve on that CPU that will kill the system, and the
30% average reserve across all boards cannot save you.





^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1997-01-22  0:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-01-21  0:00 CPU & Memory opinions wanted Ron Thompson
1997-01-22  0:00 ` Michael F Brenner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox