home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / isis / 217 < prev    next >
Encoding:
Text File  |  1992-08-12  |  4.7 KB  |  113 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!honir!rcbc
  3. From: rcbc@honir.cs.cornell.edu (Robert Cooper)
  4. Subject: Re: Abcast performance
  5. In-Reply-To: hss@bigbird.bu.edu's message of 13 Aug 92 00:40:23 GMT
  6. Message-ID: <RCBC.92Aug12222023@honir.cs.cornell.edu>
  7. Sender: rcbc@cs.cornell.edu (Robert Cooper)
  8. Reply-To: rcbc@cs.cornell.edu
  9. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  10. References: <93520@bu.edu>
  11. Distribution: usa
  12. Date: Thu, 13 Aug 1992 03:20:23 GMT
  13. Lines: 98
  14.  
  15. Himanshu,
  16.  
  17. Your tests are explained by two factors:
  18.  
  19. (1) The abcast algorithm used by the "bypass" protocols works like this;
  20.     - sending member sends message to all members of group
  21.     - each member puts this message in a queue
  22.     - oldest member of group sends out a "sequencing" message to all
  23.       members of the group. This ensure the total abcast ordering in the
  24.       group, even with concurrent abcasts from different group members
  25.     - on receiving the sequencing message, all members deliver the message
  26.       to the application.
  27.  
  28.     In the case where the sending process is the oldest member the first step
  29.     is skipped.
  30.     This causes about a much faster response time between the oldest
  31.     member of the group the the other members. In fact, smart Isis users
  32.     often try to take advantage of this knowledge to speed up their programs.
  33.  
  34. (2) By using abortreply you are probably confounding the results.
  35.     When the sender gets the abortreply
  36.     it stops listening for for further replies and returns immediately.
  37.     When the oldest member of the group sends the abortreply, it does so
  38.     without putting the message out on the wire. This internal software path
  39.     is very fast. In the other-than-oldest-member case, the extra delays
  40.     involved in the remote communication may well result in the nullreply
  41.     getting to the sender before the sender has got its own abortreply back.
  42.     The cost of handling the nullreply+abortreply might also explain some
  43.     the differences. Its hard to say, but to remove this possibility, 
  44.     send the original message in "exclude sender mode", using abcast_l
  45.     with the "x" option, and ask for ALL replies. This should achieve the 
  46.     effect you want of waiting for the remote member to reply.
  47.  
  48. For the record, here was Himanshu's original posting:
  49.  
  50. In article <93520@bu.edu> hss@bigbird.bu.edu (Himanshu Sinha) writes:
  51.  
  52.    Path: cornell!batcomputer!caen!uunet!olivea!bu.edu!bigbird.bu.edu
  53.    From: hss@bigbird.bu.edu (Himanshu Sinha)
  54.    Newsgroups: comp.sys.isis
  55.    Subject: Abcast performance
  56.    Summary: Abcasts sent by the first member of a group are 4-6 times faster than
  57.    Message-ID: <93520@bu.edu>
  58.    Date: 13 Aug 92 00:40:23 GMT
  59.    Sender: news@bu.edu
  60.    Distribution: usa
  61.    Organization: Computer Science Department, Boston University, Boston, MA, USA
  62.    Lines: 47
  63.  
  64.    Here is the gist of an experiment that I conducted.  
  65.  
  66.    I have two processes P1 and P2 running identical programs running on different
  67.    hosts. Each process waits (using isis_select) for the user to enter an integer,
  68.    NumOfTImes, and makes NumOfTimes abcasts to the group "testgroup" of which both
  69.    P1 and P2 are members. The abcast waits for 1 reply.
  70.  
  71.    Upon receiving a message, the receiver checks if the message has been
  72.    sent by itself. If it is, it calls abortreply() otherwise it calls nullreply().
  73.  
  74.    I measure the response time for the NumOfTimes abcasts. P1 and P2 do not abcast
  75.    at the same time.
  76.  
  77.    My observations were:
  78.    1) If P1 joined the group before P2 then its response time for a certain number
  79.    of abcasts was about 4-6 times faster than the response time of P2 for the same
  80.    number of abcasts.
  81.  
  82.    2) If P2 joined the group before P1 then P2's response times were about 4-6
  83.    times faster.
  84.  
  85.    Here are some numbers:
  86.  
  87.    When P1 joins before P2:
  88.    Num of abcasts       Response Time for P1         Respnse Time for P2
  89.  
  90.            1           3653 usecs                 19696 usecs
  91.            10          33606 usecs                          141856 usecs
  92.            100              318263 usecs                   1 secs 335790 usecs
  93.            1000      2 secs 811663 usecs                  13 secs 606533 usecs
  94.  
  95.    When P2 joins before P1
  96.    Num of abcasts       Response Time for P1         Respnse Time for P2
  97.            1                  12473 usecs                          3182 usecs
  98.            10                134268 usecs                         28624 usecs
  99.            100        1 secs 342105 usecs                        268750 usecs
  100.            1000      13 secs 509179 usecs                 2 secs 353236 usecs
  101.  
  102.  
  103.    Question:
  104.    How is this difference accounted for? I added a third process and a fourth
  105.    process. The factor seemed to drop around 3 but I did not do enough reps to
  106.    give any numbers.
  107.  
  108.  
  109.    THanks
  110.    Himanshu
  111. --
  112. -- 
  113.