Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!cornell!mak
From: mak@hermod.cs.cornell.edu (Mesaac Makpangou)
Newsgroups: comp.sys.isis
Subject: Re: ISIS RPC timing figures
Message-ID: <34505@cornell.UUCP>
Date: 21 Nov 89 16:30:00 GMT
Sender: nobody@cornell.UUCP
Reply-To: mak@cs.cornell.edu (Mesaac Makpangou)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 50

In article <34468@cornell.UUCP> Ken writes:

>For example, if you break down the 10ms for the local RPC 2-byte case,
>you get about 7.2ms in the IO calls and select, .5 in the windowing code,
>.3ms to rebuild the packet, and 2.0 doing task create and building the message
>and reply.  Note that one can get a UDP ping-pong for 2-byte packets to run
>much faster -- I get a figure of between 4.6 and 5.0ms, but the cost of
>sending larger packets (due to ISIS overhead), calling select for two
>open file descriptors, and using sendmsg with 3 or 4 "iovector" entries
>rather than just 1 causes a signifcant overhead amounting to at least
>2.2ms;

Is the number of "iovector" equal to the number of fields 
(both user and system fields) in an ISIS messages? 

> the cost varies with the packet size.

The general argument you often used to advcate the pyggibacking mechanism for
the previous versions of the system is that you believed there is no significant
overhead due to the pyggiback mechanism.

Does the fact that your measurement shows that "the cost varies with the packet size"
change your mind?

>Bandwidth runs at betwen 280kbytes and 360kbytes/second for the larger
>packet sizes.  For a 10Mbit ether, this is pretty respectable (TCP
>is faster but has a kernel implementation).

Year ago, I made few measurements of TCP on SUN 3/60
at the user level. I got a bandwidth of about 280kbytes with packets of
size 1024 bytes. But I noticed that with packet of size 1400 bytes the bandwidth
was around 250kbytes. For certain reasons, I did not try larger packets.

Do you mean that for a certain larger size of TCP packet, I could get better
bandwidth than the one I got with size 1024? Does anyone know what is the
TCP packet size providing the fastest user bandwidth?

A more general question:
-----------------------
Why 2, 2048, 4098, 8192, ... ?

Most people provide measures for a NULL RPC (i.e. no argument and no treatment).
Why don't you provide this figure too? I mean does it exist any reason or is it
just because there was particular reason to do so?

RPC litterature say that RPC messages tend to be 
small (i.e. 4, 16, 32, 64, 256, 512, 1024 bytes). Does it any particular
reason to jump from 2 bytes to 2kbytes?

Mesaac