Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!ucsd!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: ISIS RPC Performance figures
Message-ID: <34500@cornell.UUCP>
Date: 21 Nov 89 14:24:46 GMT
Sender: nobody@cornell.UUCP
Reply-To: ken@cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 36


I got some email asking me to clarify a few things:

1) All of these figures are for the new BYPASS mode; in the existing
   system performance is substantially worse.  I don't have figures
   comparing "BYPASS" and "non-BYPASS" right now, but will include this
   in the eventual article on the BYPASS facility

2) BYPASS mode doesn't do piggybacking in its CBCAST implementation, so
   when I refer to overhead on a 2 byte packet I meant overhead due to
   fields ISIS puts in (destination addresses, sender, sequence number,
   acknowledgement information, sequence numbers used by CBCAST as part
   of the BYPASS protocol, activity id, etc).  The amount of this stuff
   varies but because an inter-site packet is really a message containing
   other messages, and because each has its own header, 220 bytes isn't
   such a huge amount of overhead (this is in response to a comment that
   "200 bytes of overhead on a 2 byte message sounds like a bug to me").
   The overhead is fairly constant regardless of how big the message gets.

3) select, sendto, sendmsg and recvfrom are UNIX system calls.  sendto 
   wants a buffer with the data contiguous in it while sendmsg takes a list
   of <base,len> pairs and "gathers" the data.  ISIS generates a <base,len>
   pair for each message/embedded message it sends and for each indirect
   reference to data (from the new %*D[] format item).  My messages were
   generally a single message enclosing a single "user" message with a 
   single indirect reference field, hence they typically looked like:
	<base0,128><base1,128><data_ptr,data_len>
   this is why I used sendmsg, although the 1.4ms overhead of doing so (in
   both directions, since my RPC and its reply had the same size) was so high
   that we might be better off using sendto all the time, and copying first.

4) Yes, my table was missing a column of information -- the UDP times.  I
   decided the column was confusing in my raw data and deleted it.  Sorry if
   this made the message itself confusing.  Those numbers weren't directly
   computed as part of the test, in any case, whereas the rest of the table
   is the output of an actual run of a test program.