RE: Info-cvs digest, Vol 1 #209 - 16 msgs

[Graeme . Vetterlein]

Cheryl,

I don't know your background, so if this is teaching you to suck eggs,
sorry.

Many people (typically my employers at the time) confuse network speed
with throughput. 

If I open one (or several) ports from machine A to machine B, with
a 100 Mega-Byte link, it's possible (with suitable tuning) to SEND (only)
100 Mbytes
per second (ish) over that link.

If I run a small program on machine A talking to another program on machine
B, consider what happens.

        progA needs to run, machineA schedules it ASAP (assume a light
machine load)
        progA runs and needs to write a 'HELLO' msg on a TCP port it does a
write
        System call, switch to kernel mode HELLO starts it decent of the
stack
                ProgA now does a read and goes to sleep ...
        The nagel algorithm (probably) kicks in an holds the HELLO awaiting
more input
        After some time the driver decides "that's all that's coming" and
starts the send
        ...various bits of H/W magic ... lets assume INFINITE bandwidth ...
zero time
        On machineB a packet arrives and starts it way up the stack.
        The packet is destined for progB, progB is now marked ready to run.
        Time passes, assume a lightly loaded machine, progB starts to run
        It reads from the socket, the string is 'HELLO'
        The codes decides to reply 'HI', 
        progB writes a 'HI' msg on a TCP port it does a write
        System call, switch to kernel mode HI starts it decent of the stack
                ProgB now does a read and goes to sleep ...
        After some time the driver decides "that's all that's coming" and
starts the send
        ...various bits of H/W magic ... lets assume INFINITE bandwidth ...
zero time
        On machineA a packet arrives and starts it way up the stack.
        The packet is destined for progA, progA is now marked ready to run.
        Time passes, assume a lightly loaded machine, progB starts to run
        It reads from the socket, the string is 'HI'

Well so far we have sent 5 bytes and received 2 over an infinite speed
network connection.

HUH! Well you're not doing file transfer the two processes need to handshake
and that (as you see) takes time.

What can you do?

        1: Use a different algorithm (i.e. change the CVS protocol) ... bad
move
        2: Change some TCP options, e.g. NODELAY to stop at least one of the
delays (the code
                may already do this, I've not checked) This will make more
expensive network traffic
            and CPU time but should reduce elapsed time. Last time I did
this it was around
            1000 times faster :-)

        3: Consider the operating system you run. Solaris or SPARC for
example has a very short
           path to handle interrupts (60 instruction I recall) so responds
faster to external
           events.




        


> Message: 15


> Date: Thu, 04 Jan 2001 16:51:23 -0600
> From: "Cheryl Tipple" <address@hidden>
> Organization: Motorola Semiconductor Products Sector
> To: address@hidden
> Subject: CVS Performance
> 
> This is a multi-part message in MIME format.
> --------------86C52BF226CB80BACE584C8F
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> It appears we have a performance problem within our CVS 
> system.  We are
> not able to make use of more then approximately 5% of the CPU on an
> overall basis.  Our network bandwidth should be sufficient, 
> we are using
> 100 base T, which is far from saturated.  We are using 1G 
> port into the