Mars Rover Controlled By Java

  • Thread starter Michael N. Christoff
  • Start date
A

Anne & Lynn Wheeler

A. G. McDowell said:
I would be very interested to hear more about increasing the
effectiveness of testing beyond all recognition. I am a professional
programmer in an area where we routinely estimate the testing effort as
about equal to the programming effort (in terms of staff time, but not
necessarily staff cost). Do you have references? As a token of sincerity
I will provide references for what we seem to agree is commercial
practice (whether it should be or not):

when we were doing the original payment gateway
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we set up a test matrix ... not for the sotware ... but for the
service. nominal payment infrastructure trouble desk did 5 minute
problem first level problem determination ... however that was for an
infrastructure that was almost exclusively circuit based.

while it was possible to translate the (payment) message formats from
a circuit based infrastructure to a packet based infrastructure ...
translating the circuit-based service operation to a packet-based
infrastructure was less clear cut (merchant/webhost complains that
payments aren't working ... expects internet/packet connection to be
much less expensive than direct circuit ... but at the same time
expects compareable availability).

The claim has been that coding for a service operation is 4-10 times
that of a straight application implementation and ten times the effort
because of needing to understand all possible failure modes
.... regardless of whether they are characteristic of the software or
hardware or some totally unrelated environmental characteristic.

in any case, one of the issues was detailed analysis of existing
trouble desk circuit-based problem determination procedures and being
able to translate that into a packet-based (internet) environment and
still attempt to come close to the goal of being able to perform first
level problem determination in five minutes. When we started there
were cases of trouble ticket being close NTF (no trouble found) after
3hrs of manual investigation.

of course this was also at a time ... when it was difficult to find
any ISP that even knew how to spell "service level agreement".

aka ... it is possible for software to perform flawlessly and still be
useless.

some of this came from doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

misc. related past threads
http://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
http://www.garlic.com/~lynn/2001e.html#48 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002.html#28 Buffer overflow
http://www.garlic.com/~lynn/2002.html#29 Buffer overflow
http://www.garlic.com/~lynn/2002e.html#73 Blade architectures
http://www.garlic.com/~lynn/2002f.html#24 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#11 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#12 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003l.html#49 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
 
A

arne thormodsen

I hate to barge in and short-circuit a really very interesting
discussion, but
I think a point has been missed.

The SW on the Rover was designed from the start to be remotely
debugged
and patched. This is a truely wonderful thing. Why spend the effort
it takes
to design bullet-proof SW when you can spend it designing fixable SW?

--arne (I'll take my answer off the air... ;-)
 
J

Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=

Example: the priority inversion bug that hit a previous probe

....Mars Pathfinder...
had apparently shown up in testing but been ignored, because it
wasn't what they were looking for at the time.

Of course, that project was run on a shoe-string budget (relatively),
the priority-inversion-caused resets occured sporadically (only a few
times during maybe a year's worth of testing) and unreproducibly, and
most importantly: those guys had a strict deadline, and a lot of other
problems to solve. A rasonable trade-off, all things considered, IMO.

Jan
 
N

Nick Maclaren

|> >
|> I would be very interested to hear more about increasing the
|> effectiveness of testing beyond all recognition. I am a professional
|> programmer in an area where we routinely estimate the testing effort as
|> about equal to the programming effort (in terms of staff time, but not
|> necessarily staff cost). Do you have references? As a token of sincerity
|> I will provide references for what we seem to agree is commercial
|> practice (whether it should be or not):

Regrettably not :-( I have seen references, yes, but they were
usually incidental remarks and I can't now remember exactly where I
saw them. The trouble is that they dated from the days when such
things were 'just done' and the techniques were often passed by
word of mouth, or were regarded as so obvious as to be not worth
describing.

One aspect you may be able to find is in the testing of numeric
code. One standard form of targetting is to increase the coverage
of the 'difficult' or boundary areas, because a relatively small
number of tests is adequate for the main sections. I know that
something similar has also been done in compiler test suites.

The only 'theoretical' reference I know of is to a related area:
Monte-Carlo methods. But, if you regard the problem as estimating
the number of bugs, then that is immediately applicable. I use
Hammersley and Handscomb, but that may be out of print.

Thanks for the references. There is certainly stuff dating from
the 1960s and early 1970s, but it could be the devil to track down.
NAG has certainly been doing it since it started (early 1970s),
in the numeric context.


Regards,
Nick Maclaren.
 
C

Carsten Fritz

Uncle said:
Local atmospheric pressure is 7-10 torr. Earth sea level is 760
torr.

1 torr = 4/3 hPa (hekto Pascal), for those of us who are more familiar with
the metric system.

Carsten
 
A

Anne & Lynn Wheeler

A. G. McDowell said:
I would be very interested to hear more about increasing the
effectiveness of testing beyond all recognition. I am a professional
programmer in an area where we routinely estimate the testing effort
as about equal to the programming effort (in terms of staff time,
but not necessarily staff cost). Do you have references? As a token
of sincerity I will provide references for what we seem to agree is
commercial practice (whether it should be or not):

this might also be considered a characteristic difference between
platforms derived from batch oriented systems and platforms derived
from interactive oriented systems.

for 40 years or more, batch systems have tended to provide relatively
clear diagnostic information for the application owner ... since the
application owner wasn't around went their program ran; one specificly
clearly diagnosed & reported item for those 40 some year period has
been space full condition.

interactive platforms have tended to be much more laissez-faire about
providing diagnostics for such things. i've seen payroll application
ported from batch platfrom to an interactive oriented platform
.... where the sort would fail because of space full condition ... but
the error didn't get propogated appropriately thru the rest of the
infrastructure. As a result, checks got printed ... but not with
exactly the values expected. some post mortem analysis seemed to
indicate that assumptions were made about individual applications
indicating interactive error message to an human in attendance ... and
the human taking the appropriate action.

now some number of the batch platforms for possibly 20 years now
.... have had facilities that could take advantage of batch paradigm
error infrastructure and for conditions like space full ... take
automated proscriped graceful recovery actions (i.e. there is deadline
for getting checks out and can't rely on the vagaries of being able to
count on some human based mediation).

some fundamental issue about not only trying to turn out perfect code
.... but also providing an instrumented infrastructure that recognizes
errors will probably happen ... and in the absence of direct human
mediation ... other types of facilities need to be provided
(frequently a characteristic differentiation between batch-oriented
platforms and interactive-oriented platforms).

some random posts on batch vis-a-vis interactive paradigms
http://www.garlic.com/~lynn/96.html#8 Why Do Mainframes Exist ???
http://www.garlic.com/~lynn/98.html#4 VSE or MVS
http://www.garlic.com/~lynn/98.html#18 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/98.html#51 Mainframes suck? (was Re: Possibly OT: Disney Computing)
http://www.garlic.com/~lynn/99.html#16 Old Computers
http://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
http://www.garlic.com/~lynn/2000.html#81 Ux's good points.
http://www.garlic.com/~lynn/2000.html#83 Ux's good points.
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001l.html#4 mainframe question
http://www.garlic.com/~lynn/2001n.html#90 Buffer overflow
http://www.garlic.com/~lynn/2002.html#1 The demise of compaq
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
http://www.garlic.com/~lynn/2002h.html#73 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002n.html#41 Home mainframes
http://www.garlic.com/~lynn/2002o.html#0 Home mainframes
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2003e.html#11 PDP10 and RISC
http://www.garlic.com/~lynn/2003h.html#56 The figures of merit that make mainframes worth the price
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2003n.html#46 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004.html#41 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004.html#43 [Fwd: Re: Mainframe not a good architecture for interactive w
http://www.garlic.com/~lynn/2004.html#47 Mainframe not a good architecture for interactive workloads
 
G

Greg Gauthier

This is all remarkably fascinating!

Just one question:

What does it have to do with Java?

Thanks,
Greg
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top