🚀 go-pugleaf

marc@r-node.gts.org (Marc Fournier - Sys Admin) writes:
: >
: 	My understanding is that 'g' spoofing gets rid of the need
: for the modem to send the 'acks' to the host, with the modem's
: themselves receiving and interpreting them.  This helps increase
: the throughput by reducing the load on the modem<->computer
: connection because no 'acks' are being transmitted except from 
: modem<->modem :)

No, thjis simply cannot be.
The uucico on the sending host HAS to see acks "from the other end".
Spoofing means the modem is sending the ACKS back, not the remote host.
The remote host does send ACKs, but the remote modem eats them.
modem-to-modem acks are within PEP, and are not the ACKS you are
thinking of here.
See diagram below.

LHSide host is sending.  For every packet it sends, the modem
IMMEDIATELY sends back an ACK and stores the packet internally.

The modems have their  own packet protocol, PEP, whcih is running ASYNC,
for the most part, to the host packets.  They only "syncronise" to
refresh or dump.  If the PEP has to resent (etc) the hosts don't see it.

The size of the PEP packets, their window, etc, is independant of the
host connection.

Think of it as a protocol converter like Black Box (tm) sell.

You can change the Modem-to-modem protocol (as the WB has just done)
without changing the host-to-modem protocol.
Hence it doesn't matter if the host protocl is inefficient, since that
is not what goes over the line.  To boost performance, just up the
host-to-modem speed.  Again, as the WB has just done, and as the
original 'blazer did back in the days of 2400 baud modems to give us
19200.  

     LOOP 1			LOOP 2			 LOOP 3

		+-------------+          +-------------+
   +----------->|             |<========>|             |------->
Host            |   Modem     |  PEP     |  Modem      |
   <------------|             |<========>|             |<-------+
            ACK +-------------+          +-------------+


The real limitation is the size of the buffers and the speed of the
host.  Assume you have a 100MByte modem buffer.  You drop your 1K mail
message into it using uucp-g at a DTE of 56K using (3,64).
Lets not even think about computing hos short a time that is.
PEP screams it across... 56K DTE the other end grabs it.
Now the remote host has to squirril it away on its disk.  
Ha! delay!   Then it has to send the "C"onfirm back.  More delay.
All this delay is the same whther you are using a DTE of 56K or a DTE of
9600.

Marc, you're running SVR4, right?
There is an option to monitor the time spent in each part of the
process, "perfstats" I think its called.  Enable that, then run the
output through a perl/awk filter to see where the time is being spent.
You get system-user-real for each of setup, transfer and complete for
each message.  

I did this once and was astounded to see the delays "at each end".
talking to one heavily loaded site - a Sequent S81 - the time between 
the file transfers was half as long again the transfer itself for files
around the 100K mark.   There is also dead time between bursts of
packets, a phenomena which seems unique to the telenit because of its
buffering.  A non telebit would have a pause between the apcket because
the ACK would have to come from the remote host.


--
Anton J Aylward