[comp.sys.isis] More on performance of ISIS

ken@gvax.cs.cornell.edu (Ken Birman) (02/19/91)

I got two good questions back on my posting...

1) The transactional crowd suggests that, if an ISIS multicast is comparable
to 12 RPC's, why not build over transactions at comparable cost.  The point
I was trying to make (unsuccessfully?) is that the second and third "phases"
of the ISIS protocol are overlayed on the first phase of the next multicast
if possible, so the ISIS protocol looks quite a bit cheaper.  I don't know
of any transaction system that has this property, and although you might
be able to get something like this working over RPC, it won't be simple.

2) Some people at company XYZ did fairly careful measurements of ISIS RPC and
got anomalously poor performance.  On a SUN 3, where a null ISIS RPC
should cost about 9.6ms in bypass mode, they got 22ms.  (On a SUN4
we get about 7.4ms; they presumably would see 16 or 18).

This sort of result points to an old ISIS bug whereby an extra ack packet
is sent for every CBCAST.  You can tell by looking at the inter-client
transport statistics (call cl_dump(-1,"") at the end of your test
program): if there are ANY ack's at all, even 1 or 2 total, this would
be a surprise in a test doing nothing by BYPASS cbcast.  If you get
one or more acks per RPC, ISIS is acting very buggy.

So, the company XYZ people are either running an old copy of ISIS or, perhaps,
the public source doesn't have the fix for this basic and rather simple
bug.  

The fix was in something called isis_ondrain, which was triggering
prematurely.  I thought we fixed this when we put ISISV2.1 out in
October last year.  If not, I'll need to dredge up the fix, which
will take a while since we are busy... but, V3.0 and V2.2 will certainly
not have this ancient problem...  Not recalling exactly the fix, I
can't quickly check to see if the public version has this problem or not.
But, you can easily do so: do 1000 RPC's and call cl_dump...  (or
measure the number).

Now, 7.4ms for a null RPC is quite a bit worse than the SUN 4 figure
of 3.4ms as seen by the same group of company XYZ, but this gets back to the
points made in my prior posting.  (XYZ is a real company, but I don't
know if they want their name visible here)

-- Ken