Path: utzoo!attcan!uunet!cs.utexas.edu!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 timing figures
Message-ID: <34507@cornell.UUCP>
Date: 21 Nov 89 17:54:37 GMT
References: <34505@cornell.UUCP>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 61

In article <34505@cornell.UUCP> mak@cs.cornell.edu (Mesaac Makpangou) writes:
>
>Is the number of "iovector" equal to the number of fields 
>(both user and system fields) in an ISIS messages? 

Our inter-site messages are packed, one or more per UDP transmission.
If there are <n> messages in a UDP packet we send <n+1> io vectors,
plus one additional one for each indirect data reference from a %*X
format item (new in ISIS V2.0).


>The general argument you often used to advcate the piggybacking mechanism for
>the previous versions of the system is that you believed there is no
>significant overhead due to this mechanism.
>
>Does the fact that your measurement shows that "the cost varies with the
>packet size" change your mind?
>

The BYPASS code still uses piggybacking, but not for the types of operations
we measured (which involve direct IO between processed without involving
the protocols server).  By the time you pay the 20ms or so of overhead
for going through protos, I still doubt that a 2 or 3ms difference on the
inter-site communication cost in order to send an extra chunk of data
makes any significant difference.

Basically, IO costs are completely constant for a given number of INET
packets, each of which holds 1500 bytes.

Basically, I continue to feel that piggybacking is having no major performance
impact on ISIS, and that it isn't happening very much in "real" applications.
Unfortunately, the issue is hard to quantize and nobody has wanted to build
a simulation to study it in more detail.

Note also that with the new scope features that are built into the ISIS
cbcast algorithm, piggybacking is limited in any case.

There are situations where piggybacking would kill you.  A good example
is in our "YP" server, which wouldn't want to respond to requests using
cbcast.  For cases like this, I am adding a reply_l("f"...) option to ISIS
in V2.0, which will use a FIFO broadcast instead of cbcast for its reply.
But, this only matters to people designing servers, which seems to be a small
(empty set?) subgroup of ISIS users.

> .... some questions about TCP

My comment was based on "hearsay".  I didn't actually measure TCP performance.

>Most people provide measures for a NULL RPC (i.e. no argument and empty reply).
>Why don't you provide this figure too?   Why not 16, 32, 64, 128...

This is a good point.  Our test showed essentially identical performance
values (to a fraction of a millisecond) for all packet sizes from 0 to 
1k.  2k forces UDP to send two INET packets and this is the first time
one sees a performance change.  I didn't use 0 because my test program
dumped core in that case.  I need to check into this, obviously, but the
figure would have been identical for 0...1350 or so, in any case, with
the first change occuring as ISIS switched to two INET packets instead of
one.

Ken