From: naddy@mips.ruessel.sub.org (Christian Weisgerber)
Newsgroups: comp.dcom.modems
Organization: My Individual Private Site
Subject: Re: Bad Experience Seeking 2400 bps, v.42bis
Reply-To: naddy@mips.ruessel.sub.org
X-Software: HERMES GUS 1.10 Rev. Dec 18 1992
Date: Sat, 23 Jan 1993 00:59:04 CET
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <9301140239.AA17511@cs.utexas.edu>, NBECC::KENNEY writes:

[... long explanation deleted...]

Yes, I can understand the argument that "it makes sense to reallocate
the error correction and data compression tasks to the host computer".
(Actually, in a discussion in comp.dcom.isdn some people suggested to
take the compression out of the transmission layer altogether.)

However, my main concern regarding Rockwell's specific product was
from the user's point of view:

When a user buys a modem labeled "MNP/V.42/V.42bis" today he assumes a
traditional design. I think the RPI approach would be considered
inferior and modem vendors seem to share this opinion. You won't
anywhere see a RPI modem advertised as needing additional driver
software, at most this fact is mentioned in the small print.

Also, not all the world is a DOS machine. Not all the world even is a
PC. There are different hardware platforms and especially in the PC
market lots of different operating systems. Rockwell cannot provide RPI
support for all of these.
Does Rockwell provide a portable (say C code) MNP/LAPM/V.42bis RPI
driver template that could rather easily be ported to different
environments? If so, this would ameliorate the situation. However, my
current state of information and impression is that there is only RPI
driver support for MS-DOS and both driver code and RPI specifications
are proprietary.

> The Rockwell RPI, in conjunction with Rockwell modem hardware, provides a fully
> synchronous V.42bis LAPM data stream to the other modem - there is no inherent

I assume RPI simply provides a protocol that allows the DCE to handle
asynchronous<->synchronous (HDLC) conversion, similar in concept to
Hayes' AutoSync. Correct?

> In fact, it is probably preferable for the '486 to
> do your data compression than an 4 MHz 8 bit microcontroller.

Actually these "4MHz 8 bit microcontrollers" are doing quite well in
current 2400/V.42bis modem implementations at negligible extra cost
compared to a 2400/none modem.

> The result of the RPI based V.42bis/MNP5 is only to provide the lowest cost
> solution for a full V.42bis/MNP5 featuresd modem. The idea is to provide a cost
> benefit to the end user - it is not a scam, it is the 'real thing'. 

Excuse me, but the idea behind offering a product is to _succeed_in_the_
_market_. Obviously a singel-chip modem core is very attractive to modem
manufacturers. This may result in end products with an increased
performance/cost ratio, and finally it _may_ benefit to the end user.
However, this is the consequence not the initiative.

> BTW, The ZOOM modems I have seen indicate the V.42bis/MNP5 is "RPI Based" - 
> perhaps the person selling it to you should have made that clear.

This did not happen to me; I don't remember who reported this. But it
clearly demonstrates my point: These modems are sold as fully capable of
MNP/LAPM/V.42bis. The average modem buyer certainly has an idea what to
expect from MNP etc. On the other hand "RPI-based" is widely unknown and
very counterintuitive to most user's expectations. This is why I will
continue to spread information about RPI as a WARNING!

I already received requests by concerned users how to use the RPI driver
with their favorite non-RPI-sensitive DOS (!) comms application. These
people were tricked into thinking they'd buy a full MNP/V.42bis modem
only to find out that they can't use this important feature in their
environment. Pardon the language but on behalf of those users I'm
_pissed_off_.

Rockwell could have forseen the result of their RPI chipset. However, I
doubt that licensing RPI technology explicitely forces a modem vendor to
plainly state that the resulting product is only able to deliver its
claimed performance with the supplied software driver. If Rockwell care
as much about end user satisfaction as implied by their Product Manager
they should consider insisting on such an agreement.

> Tony Zuccarino       
> Product Manager
> Rockwell International

BTW, please see my signature for the correct spelling of my name.

-- 
Christian "naddy" Weisgerber, Germany           naddy@mips.ruessel.sub.org
Newsgroups: comp.dcom.modems