home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / software / 3338 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  3.1 KB
  1. Path: sparky!uunet!gumby!wupost!usc!hacgate!nuntius
  2. From: mark@hti.hac.com (Mark Johnson)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: Testing Complex Systems
  5. Message-ID: <23103@hacgate.SCG.HAC.COM>
  6. Date: 1 Sep 92 15:23:15 GMT
  7. References: <1992Aug31.135414.5265@linus.mitre.org>
  8.      <1992Aug31.222254.19432@cactus.org>
  9. Sender: news@hacgate.SCG.HAC.COM
  10. Organization: Hughes Training, Inc.
  11. Lines: 69
  12. X-UserAgent: Nuntius v1.1
  13.  
  14. I'll provide some background in the techniques used here to get a system
  15. out the
  16. door with a concrete example of working around a serious design flaw.
  17. [long]
  18.   a.  Functional requirements testing.  Enuf said.
  19.   b.  Tracking system (& software) MTBF to indicate non-deterministic
  20. problems;
  21.       then using the system architecture and post-mortems of failures,
  22. determine
  23.       the root cause of the problems.
  24.   c.  Modelling the system tasking & data flow to provide early warning
  25. of problems
  26.       in the distributed system.
  27.   d.  Host based testing using multitasking to simulate distributed
  28. operations.  We
  29.       run the "application level" operational code on the host machine on
  30. top of a
  31.       multitasking test bed.
  32.   e.  Rerun host based testing scenarios on the target hardware to
  33. resolve problems
  34.       with compilers, bugs in target specific code, etc.
  35.   f.  Deliver systems with diagnostic routines included to aid on-site
  36. analysis.
  37.  
  38. A system I once worked on would stop working "sometimes".  It was
  39. basically a star
  40. configuration with a central computer & remote computers connected with
  41. RS-232
  42. lines.  A graphics processor was attached to one of the remote computers
  43. by another
  44. RS-232 line as well.  We had isolated the problem to dropping characters
  45. in the
  46. interrupt handler for the line to the graphics processor.  We identified
  47. a design flaw
  48. caused by excessive latency of a problem interrupt handler (PIH).  It was
  49. determined to
  50. be "too hard" to redesign this part of the system.  We did add a
  51. capability to stress
  52. this part of the system to get the MTBF's indicated below.  Normal
  53. operations had
  54. much better MTBF's that listed below.
  55.   Fix 1 was to lower the interrupt level after entry on the PIH.  MTBF
  56. grew from
  57.     5 minutes to 15 minutes.  New problem was seen when graphics line IH
  58. was
  59.     interrupted by the PIH.
  60.   Fix 2 was to recognize when graphics line IH was pre-empted, resume it,
  61. and then
  62.     complete the PIH handling at a low interrupt level.  MTBF grew to 30
  63. mins.
  64.     New problem was seen when the clock interrupted the graphics line IH
  65. & THAT was
  66.     interrupted by the PIH.
  67.   Fix 3 was to recognize that situation as well.  MTBF grew to over a day
  68. which
  69.     was OK for this application (typical runtime was less than 1 hour).
  70. Needless to say, this took several months to resolve in the field,
  71. something that
  72. should have been removed in the design over a year previously.  Testing
  73. won't fix
  74. a broken system, a robust design that can be verified is much more
  75. significant.  As
  76. a result of this problem, the systems we build here are much more robust
  77. since
  78. we review the basic system architecture & design much more closely. 
  79. Timing of
  80. the system is a very key component of that review.
  81.  
  82. --Mark Johnson <mark@bart.dnet.hac.com>
  83.