Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!fjcp60!brinkema
From: brinkema@fjc.GOV (John R. Brinkema)
Newsgroups: comp.protocols.tcp-ip
Subject: (Practically) How fast go I go?
Summary: How fast can a real tcp-ip connection go?
Keywords: Speed, tcp-ip
Message-ID: <395@fjcp60.GOV>
Date: 11 Apr 91 02:57:02 GMT
Organization: Federal Judicial Center, Washington, D.C.
Lines: 28

I am designing a rather crude 'mirrored' database system built out of
an standard database product.  The baseic idea is to copy transaction
entires in the backup-journal file over to the mirror system and post
the transactions there also.  The mirror database is read only.  If
something goes wrong (ie the transaction journal is messed up -- which
apparently happens although *I* have not experienced the phenominon) the
whole master database must be copied from the primary system to the mirror
system.  The database is about 800Mb (and growing).

The question is from your experience, how fast can this be done.  The
connection between the two systems will be Ethernet;  the two systems
will be quiescient at the time; they are 486-based running Unix, Enet
boards are (currently) 'dumb' with tcp-ip the 'standard' protocol.
The two machines are physically next to each other (ie. no internet to
deal with - just Ethernet (Enet) ).

Specifically:
1) where are the bottle necks in such a configuration: the cpu's, disk, the
network (Enet), the protocol?

2) I am willing to consider writing a network program using special
protocols to do the transfer if the transfer speed would significantly
be reduced.  So -- if the time to transfer the file using (Unix's) rcp
command is '1', what factors would I get if I used ftp; socket/tli level
routines in my own program; lower level (ip-connectionless) routines in my
own programs; direct Enet access (if I can do it), via my own routines.

Rule of thumb or numbers are fine. tnx.   jb.