home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / isis / 238 < prev    next >
Encoding:
Text File  |  1992-09-08  |  4.5 KB  |  86 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!cs.utexas.edu!usc!rpi!batcomputer!cornell!ken
  3. From: ken@cs.cornell.edu (Ken Birman)
  4. Subject: More warnings about time warps
  5. Message-ID: <1992Sep7.185432.26204@cs.cornell.edu>
  6. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7. Date: Mon, 7 Sep 1992 18:54:32 GMT
  8. Lines: 76
  9.  
  10. I spent part of Labor Day staring at one or perhaps two ISIS bugs
  11. that can be triggered (only?) by big scheduling differences between
  12. members of a process group.  For example, say that A,B,C are in 
  13. group G and that D joins and B crashes between 1:00pm and 1:03pm.
  14. Normally, one would expect A and C and D to emerge in consistent
  15. states by the end of this sequence.
  16.  
  17. Say that C is not cooperating with the ISIS scheduler, though, and
  18. tends to hold the CPU for minutes at a time without letting ISIS
  19. run (and, lets add another half dozen or so members to the group
  20. to liven things up, and have them all do this sporadically -- ignore
  21. ISIS for a minute or two at a time).
  22.  
  23. On your console, this will provoke vigorous complaints from ISIS
  24. about "Time warp: 39.37 seconds" -- or whatever the delay was.
  25.  
  26. Internally, though, this creates an extreme of asynchrony, in which
  27. the slow processes may be several group views and hundreds of
  28. messages behind the fast ones, and in which the fast ones may be
  29. close to trying to kill the slow ones off for non-responsiveness.
  30.  
  31. In principle, our protocols handle this case, but in practice, we
  32. seem to have two remaining bugs in V3.0.6 (V3.0.5 or previous
  33. had significantly MORE than "only" two problems in this case).
  34. The observed problems are:
  35.     Group can hang, not permitting further joins/departures and not
  36.       killing members.  If you look at a client log you will find
  37.           some members "waiting for flush viewid 154.0" (for example), but with
  38.       "Got flush viewid 153.0" listed on the same channel.
  39.  
  40.           Apparently, in some timer related situation the flush protocol
  41.           either resends the flush for 153.0 or the protocol for 154.0
  42.           advances without using a fall-back scheme and gets confused when
  43.       the 153.0 flush message shows up late.  This jams the channel
  44.       between the processes involved and leaves the group stuck, since
  45.           ISIS is not tolerant of this sort of implementation bug.
  46.  
  47.     Perhaps, RPC's via protos (non-bypass) can "lose their replies".
  48.      One sees an RPC pending in the client log, but no sign of the
  49.      reply and no sign of a corresponding task in the protos log.
  50.  
  51. Again, these bugs are NOT seen except in combination with timewarp
  52. complaints in the 60-120 second range, which are always due to software
  53. that doesn't schedule ISIS in a timely manner.  In a sense, these are
  54. ISIS bugs triggered by unreasonable behavior in the application itself.
  55.  
  56. We will fix our software, but in the meantime there is a work-around for
  57. both problems.  Code with long timewarps should use the ISIS_USEITIMER
  58. option and bracket long compute segments with a call to THREAD_LEAVE_ISIS()
  59. before the long computation and THREAD_ENTER_ISIS() after it.  This will
  60. run ISIS off of timer interrupts during the long computation and eliminate
  61. the timewarps.  Since the group members will now advance more or less
  62. at once (at least, no really extreme delays will occur), the timer 
  63. associated with very slow flush protocols won't trigger (the timeout underlying
  64. the bug is actually 15 seconds, but I think you need a pretty extreme
  65. situation to see the problem, which didn't show up at all in testing).
  66.  
  67. The fix will be in the V3.0.7 release, which only contains bug fixes.
  68. The other problems V3.0.7 will fix include a bug when isis_disconnect()
  69. is called after a fork by the child process (workaround: instead,
  70. the child should call isis_has_crashed(-1); other uses of isis_disconnect()
  71. are fine though and should NOT call this isis_has_crashed in this manner!)
  72. And, we are fixing a duplicate declaration that upsets some C compilers,
  73. but not others, an alignment issue raised by our inclusion of BSD
  74. malloc code for use with ISIS_USEITIMER ("purify" wants 8-byte aligned
  75. memory allocation for some reason), and a bug that can cause a program
  76. to hang during reconnect after a disconnect at an "inopportune" stage
  77. of one of our protocols -- very hard to trigger.
  78.  
  79. V3.0.7 will be out in about six weeks.  It won't include any new code
  80. at all -- only these bug fixes.
  81.  
  82. -- 
  83. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  84. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  85. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  86.