Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!bu-cs!root
From: root@bu-cs.UUCP (Barry Shein)
Newsgroups: net.dcom,net.micro.pc
Subject: Re: ibm pc and interrupt driven asynch output
Message-ID: <324@bu-cs.UUCP>
Date: Sat, 30-Mar-85 22:40:26 EST
Article-I.D.: bu-cs.324
Posted: Sat Mar 30 22:40:26 1985
Date-Received: Wed, 3-Apr-85 00:39:06 EST
References: <23097@arizona.UUCP>
Organization: Boston Univ Comp. Sci.
Lines: 24
Xref: watmath net.dcom:924 net.micro.pc:3629

>Re: Problem with remote system (4.2bsd,PDP10) dropping chars at
>1200 baud input

Yes, nuisance nuisance. Solutions:

1. If you are not doing 'raw' [ie. need to send entire 256 char set]
then you can put UNIX into TANDEM (stty tandem). This will cause
UNIX to respond with ^S when buffer is about to overflow and ^Q
when drained back down to a safe level. As long as you can quickly
stop transmission (there's a few chars of grace) you'll probably
be OK.

2. Another approach is to put about a 1/10th of a second delay after
every CR or 100 or so chars whichever comes first. This will work
in general but unfortunately the needed delay will vary with remote
system load. You may have to play around. I have used exactly
1/10th of a sec with TIP and it works most of the time on 4.2bsd
and sometimes has to be raised to 2 or 3 tenths for SYSV.

3. The only other resort is a 'smart' protocol at the other end
catching the characters and doing flow control and ACK'ing etc.
but I bet this exactly what you don't want (otherwise, try KERMIT.)

	-Barry Shein, Boston University