Date   : Wed, 13 Jan 1988 17:58:32 GMT
From   : sdcrdcf!shaprkg@burdvax.prc.unisys.com (Bob Shapiro)
Subject: Re: info about performance of different datatransfering programs

In article <531@kksys.UUCP> bird@kksys.UUCP (0000-Mike Bird) writes:
<In article <1396@obelix.liu.se> pekka-r@obelix.liu.se (Pekka Akselin [The
Mad Midnight Hacker]) writes:
<<
<<Hello!
<<Does anybody out there, in the netland, have any kind of
<<information how well different data transfering programs
<<does its job. I want to know how many bytes per second
<<each program transfers, in either direction, and what
<<buadrate gave the numbers.
<
<Unfortunately, Bytes/Second would only be applicable for the specific
<hardware/firmware combination being tested.  There is such a
<difference between disk controllers (DMA vs CPU, clock speeds, etc.)
<disk drives, the BDOS and BIOS being run, etc.  That two machines of
<supposedly the same configuration can be quite different.  So, what
<your looking for is the comparisons for the different programs done on
<the SAME MACHINE, preferably near in time.  This can best be expressed
<as in index number, with perhaps PIP being arbitrarily set to the
<index of 100.  Then, each program would have to be tested against PIP
<on the same hardware/software configuration.  Tests done on two
<different machines would almost be worthless.  Also, the same program
<may behave differently depending upon the hardware, so if your
<particular setup has, for example, a DMA disk controller, you may be
<better off with a program that takes advantage of the controller, even
<if the index number is higher than a different program that doesn't.
<
<In other words, this is a VERY subjective test.
<
<--
<===============================================================================
<Mike Bird (These opinions are mine, dammit!)   Mail paths:  bird@kksys.UUCP
-or-
<Void where prohibited by law.                       ...rutgers!meccts!kksys!bird

   I beg to differ with you.  At 9600 baud you send at a rate of about 10
bits per character or a character about once a millisecond.  Almost any
computer on the market can send at that rate so I suspect the clock rate on
the computer would have little to do with it.

   The following things affect performance in my opinion:

   1. The amount of overhead in the protocol.

   2. In certain protocols the distance between the sending and receiving
computers.  If the protocol has a "send-ahead" feature then this is not a
consideration but if each message has to be "ACKED" before the next is sent
then the turn-around time if you are going through a satellite link is quite
a large delay.

   3. The error rate on the line may affect you.  There are three types of
protocols. Those with large messages (which have a low overhead but are very
susceptible to line noise), those with small messages (which have a high
overhead but are not as susceptible to line noise) and a few protocols which
adapt their message size according to the number of retransmissions which
are required. Obviously the latter is the most efficient but it is also the
most complex.

   4. How much overhead is spent in the disk logic.  At one extreme you can
have the disks on both ends reading or writing single CPM sectors of 128
bytes in a non-DMA world.  Thus you must delay on both the sending and
receiving end for the disk.  This delay is significant and may result in
the overall time doubling or tripling.  On the other extreme is a hard disk
with DMA and very large buffers so any disk activity is rare.  There may be
literally no overhead at all in this type of environment.

   The bottom line is that the software is responsible for most of the delays
in the transmission.  I have written transmission programs which buffer 16K
inputs from a floppy disk (without a DMA) and write 16K outputs to the floppy
disk. They use very large messages and have few overhead characters in the
message.  When running "back-to-back" to transfer data from one computer to
another I have run at 19200 and can move the data at better than a 95 per
cent efficiency.  Mind you because of the "back-to-back" situation there were
very few "hits" on the line and the protocol was not very clever when "hits"
occurred but the nature of a "back-to-back" situation is that the line tends
to be error-free. Also since many of my files were less than 16K in length
the transmission tended to be "memory-to-memory" with only the original read
and the final write taking up any disk time.

   It would be my educated guess that the same transmission program would
run at about the same speed on almost any computer on the market.

                       Bob Shapiro