Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 Adelie 8/14/85; site adelie.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!adelie!barry From: barry@adelie.UUCP (Barry A. Burke) Newsgroups: net.unix Subject: Re: calling non-unix systems (really tip) Message-ID: <525@adelie.UUCP> Date: Fri, 25-Oct-85 09:06:23 EDT Article-I.D.: adelie.525 Posted: Fri Oct 25 09:06:23 1985 Date-Received: Sat, 26-Oct-85 08:05:59 EDT References: <8@dolphy.UUCP> <158900001@hpfcdc.UUCP> <384@varian.UUCP> <5219@amdcad.UUCP> Organization: Adelie Corporation, Newtonville MA Lines: 24 > BSD4.2 tip has a variable called "echocheck" which requires each > character be echoed before sending the next character. This is > probably ideal as it will send as fast as the receiving system > can accept data. Are there any systems which echo even when the > data is coming in too fast? > -- Yeah- All Prime 50 Series systems. Primos let's the asynchronous controller (AMLC, ICS) do the echo so long as it has room in it's "tumble tables". When the tables fill up, the AMLC stops echoing. HOWEVER, any un-echoed(sp?) characters are dropped as well (and if so instructed, the AMLC will stick in a NAK in the input stream to tell Primos it lost chars)... Working with "echocheck" with Primos is thus dangerous. The buffers rarely ever actually fill up, though, and if it's a problem Primos can be configured to have bigger tumble tables. I used to speak poorly about the Primos support for asynchronous devices- after getting out into the UNIX world, I learned that Primos is still a lot better than the alternatives (eg DEC). Even if it is just re-fried Honeywell support, the AMLC is faster, with less overhead, and it handles high-speed input *much* better than what I've seen from DEC/UNIX. -- LIVE: Barry A. Burke, (617) 965-8480 x26 USPS: Adelie Corporation, 288 Walnut St., Newtonville, MA 02160 UUCP: ..!{harvard | decvax!cca!emacs}!adelie!barry ARPA: adelie!barry@harvard.ARPA