🚀 go-pugleaf

In <1754@dsinet> chipc@jaws (Chip Colby) writes:

>Adam Thompson (thompsn@ccu.umanitoba.ca) wrote (in response to my query):
>: >	Does anybody know of anything that even comes close to this?
>: >	I'm not looking for the "well, you can use an X terminal, and
>: >	just start a telnet session", because than's not what I want.
>: 
>: Curious: *WHY* do you want such a thing?

>	Our current configuration employs many ASCII terminals and a Datability
>	VCP-1000 terminal server, able of functioning at a maximum of
>	38.4 KB.  Because of the nature of our application, a ridiculous
>	amount of data is being sent to the terminal, meaning that a user
>	has to wait for the screen to finish drawing these silly boxes before
>	the actual text is printed.  Because the speed with which the user
>	can get the data is critical, 38.4 KB is to slow.  A network
>	based connection is much faster.

Perhaps you aren't aware ... most ethernet connections displaying ASCII on
a screen don't get throughput much better than 9600.  For example, I have an
X terminal on my desk, with an "ASCII-terminal" mode, that is basically an
"ANSI" terminal with a telnet connection.  It gets throughput of about
10000 bps, on average.  On some of our 486sx PCs, we have tested NCSA telnet
and MS-Kermit v3.11[3.12] under FTP software's tcp/ip drivers, and Novell's
LAN Workplace for DOS[Windows]' tcp/ip drivers.  We have acheived ascii
dump rates of about 20000bps, _MAX_.  There was also a test configuration I
saw once, which was:
 486DX-66Mhz/8Mb RAM
 16-bit WD ethernet card
 FTP Software's TCP/IP drivers (commercial)
 FTP Software's Telnet/FTP package (commercial)

Results were, reportedly, ascii dump rates of about 45kbps.  Now, this
should give you some idea of what you're up against. 

>	A PC works fine, but we don' want to have to maintain the software
>	that will run on it.  Basically, we are looking for a hardware
>	solution to a software problem.  And I'm supposed to be a
>	software engineer...

>	Anyhow, don't tell me to re-engineer our application, because while
>	that is the "best" solution, it is not considered to be an
>	option (sob!).

I _CAN_ suggest another solution: use an intelligent mux/demux setup, 
which can interpret (for example) VT100 emulation.  This can remove some
of the redundancy in the data stream.  Be prepared to search long and hard,
however -- and to pay through the nose.  I've only heard of these, not
actually seen them or detail on them.  I suggest you contact DEC,Tektronix,
Cisco,Western Digital... perhaps also Wyse, Wang... 

>	I'd still like to find such a beastie, but since you are not the
>	first to suggest a PC is the best alternative (an option I have
>	been suggesting for months), I probably want something I ain't 
>	gonna get.

Sounds like.

>| Chip Colby - Software Engineer              |   Chip Colby - Watchmaker     |
>| Digital Systems International, Inc.         |   Vintage Timepieces          |
>| "Voicelink (R) Intelligent Dialing Systems" |   Member NAWCC and AWI        |
>| 6464 185th Ave. NE                          |   20006 NE 168th PL           |
>| Redmond, WA 98052                           |   Woodinville, WA 98072       |
>| (206) 869-4551                              |   (206) 788-4900              |

-Adam Thompson
 thompsn@ccu.umanitoba.ca
-- 
+----------------------------------------------------------------------+
| Adam Thompson        University of Manitoba        Computer Services |
| thompsn@ccu.umanitoba.ca                    OLC Project - Unix Group |
| "He was a real ladies' man -- big, handsome, stupid." -E. F. Russell |