phil@amdcad.UUCP (Phil Ngai) (10/22/85)
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?
--
The California Lottery is a tax on the stupid.
Phil Ngai +1 408 749-5720
UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.comlevy@ttrdc.UUCP (Daniel R. Levy) (10/23/85)
In article <5219@amdcad.UUCP>, phil@amdcad.UUCP (Phil Ngai) writes: >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? How about Unix itself? (And any other system where echo is immediate and input possibly delayed.) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!ihnp4!ttrdc!levy
romain@pyrnj.uucp (Romain Kang) (10/23/85)
In article <5219@amdcad.UUCP>, phil@amdcad.UUCP (Phil Ngai) writes: > Are there any systems which echo even when the > data is coming in too fast? The IBM mainframes I've dealt with handle asynchronous lines at half duplex. To transfer to them, you have to listen for a turnaround character; I've never been able to do it cleanly with tip or cu. If you must deal with them, you need special protocols like Kermit. -- --Romain Kang, Pyramid Technology Corporation US Mail: 900 Route 9, Woodbridge, NJ 07095 Ma Bell: (201) 750-2626 UUCPnet: {allegra,cmcl2,pyramid,topaz}!pyrnj!romain
barry@adelie.UUCP (Barry A. Burke) (10/25/85)
> 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