Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: Re: MNP make for a faster modem?
Keywords: MNP
Message-ID: <10349@mimsy.UUCP>
Date: 26 Jan 88 07:58:17 GMT
References: <3027@killer.UUCP> <6678@agate.BERKELEY.EDU> <9308@steinmetz.steinmetz.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 37

In article <9308@steinmetz.steinmetz.UUCP> davidsen@steinmetz.steinmetz.UUCP
(William E. Davidsen Jr) writes:
[re compression at higher MNP levels]
>The secret is to let the modem do speed conversion. ...
>The modem will do flow control to adjust the speed of the data ...

... and therein lies the problem.  Just *how* does the modem do
flow control?  The Telebit Trailblazer Plus has five or six different
options.  I suspect a number of modems have two:  No flow control,
or DC1/DC3 (also known as ^S/^Q) flow control.  Hardware flow
control using RTS/CTS is possible, and when it can be used, works
perfectly; unfortunately, it often cannot be used, partly because
it is technically `illegal'.

Ideally, someday, someone will define a standard for compressed
data between cooperating devices, with some sort of control built
in (windowing comes to mind), manufacturers will build terminals
and modems supporting this protocol, and everything will plug in
from one end to the other with no `special' bit patterns visible
to users.

Since without some sort of configuration---manual or automatic---
such devices will not interoperate with existing RS232C, and since
there is no installed base of such devices, there is no real drive
for this to happen any time soon.  Perhaps some of the more visionary
and capable vendors (such as I perceive Telebit to be) will help
get this started.  (And indeed, Telebit's UUCP g protocol spoofing
is a start.)

[I suppose this article warrants a disclaimer.  I am not associated
in any way with Telebit.  I am just extremely impressed with their
modems.  They are one of the few companies I have seen build clever
hardware *and* hire good programmers, rather than having the hardware
engineers do all the firmware!]
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris