Xref: utzoo comp.dcom.modems:5610 comp.unix.xenix:11015 comp.unix.i386:4096
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!chip
From: chip@chinacat.Unicom.COM (Chip Rosenthal)
Newsgroups: comp.dcom.modems,comp.unix.xenix,comp.unix.i386
Subject: Re: Error-correcting modems & uucp
Message-ID: <1147@chinacat.Unicom.COM>
Date: 11 Apr 90 04:20:33 GMT
References: <963@frcs.UUCP> <967@frcs.UUCP>
Followup-To: comp.dcom.modems
Organization: Unicom Systems Development, Austin (yay!)
Lines: 22

In article <967@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes:
>	dte interface 2400 bps, MNP4 (v22bis):		214 cps
>	dte interface 9600 bps, MNP4 (v22bis):		148 cps

What you are probably seeing is the overhead of (a possibly poorly
implemented) flow control.  Some of the recent messages in these groups
have been dancing around a point, but I'm not sure anybody has flat out
said it:

    For uucico you do not want flow control; for interactive users
    you do want flow control.

If you want to do both, then you have to make a compromise:  throughput
vs dropped chars.

If you want to test the flow control theory, you could split out the
transmitting vs receiving stats.  I would expect that the receive times
would be close, and it's mostly transmit where you are seeing the hit.
-- 
Chip Rosenthal                            |  You're not some icon carved out
chip@chinacat.Unicom.COM                  |  of soap, sent here to clean up
Unicom Systems Development, 512-482-8260  |  my reputation.  -John Hiatt