home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / dcom / modems / 19904 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  4.6 KB
  1. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!smurf.sub.org!ppcnet!sks!mcd!mips.ruessel.sub.org!naddy
  2. From: naddy@mips.ruessel.sub.org (Christian Weisgerber)
  3. Newsgroups: comp.dcom.modems
  4. Message-ID: <H.eg.sQw142IsvWs@mips.ruessel.sub.org>
  5. Organization: My Individual Private Site
  6. Subject: Re: Bad Experience Seeking 2400 bps, v.42bis
  7. References: <9301140239.AA17511@cs.utexas.edu>
  8. Reply-To: naddy@mips.ruessel.sub.org
  9. X-Software: HERMES GUS 1.10 Rev. Dec 18 1992
  10. Date: Sat, 23 Jan 1993 00:59:04 CET
  11. MIME-Version: 1.0
  12. Content-Type: text/plain; charset=US-ASCII
  13. Content-Transfer-Encoding: 7bit
  14. Lines: 85
  15.  
  16. In <9301140239.AA17511@cs.utexas.edu>, NBECC::KENNEY writes:
  17.  
  18. [... long explanation deleted...]
  19.  
  20. Yes, I can understand the argument that "it makes sense to reallocate
  21. the error correction and data compression tasks to the host computer".
  22. (Actually, in a discussion in comp.dcom.isdn some people suggested to
  23. take the compression out of the transmission layer altogether.)
  24.  
  25. However, my main concern regarding Rockwell's specific product was
  26. from the user's point of view:
  27.  
  28. When a user buys a modem labeled "MNP/V.42/V.42bis" today he assumes a
  29. traditional design. I think the RPI approach would be considered
  30. inferior and modem vendors seem to share this opinion. You won't
  31. anywhere see a RPI modem advertised as needing additional driver
  32. software, at most this fact is mentioned in the small print.
  33.  
  34. Also, not all the world is a DOS machine. Not all the world even is a
  35. PC. There are different hardware platforms and especially in the PC
  36. market lots of different operating systems. Rockwell cannot provide RPI
  37. support for all of these.
  38. Does Rockwell provide a portable (say C code) MNP/LAPM/V.42bis RPI
  39. driver template that could rather easily be ported to different
  40. environments? If so, this would ameliorate the situation. However, my
  41. current state of information and impression is that there is only RPI
  42. driver support for MS-DOS and both driver code and RPI specifications
  43. are proprietary.
  44.  
  45. > The Rockwell RPI, in conjunction with Rockwell modem hardware, provides a fully
  46. > synchronous V.42bis LAPM data stream to the other modem - there is no inherent
  47.  
  48. I assume RPI simply provides a protocol that allows the DCE to handle
  49. asynchronous<->synchronous (HDLC) conversion, similar in concept to
  50. Hayes' AutoSync. Correct?
  51.  
  52. > In fact, it is probably preferable for the '486 to
  53. > do your data compression than an 4 MHz 8 bit microcontroller.
  54.  
  55. Actually these "4MHz 8 bit microcontrollers" are doing quite well in
  56. current 2400/V.42bis modem implementations at negligible extra cost
  57. compared to a 2400/none modem.
  58.  
  59. > The result of the RPI based V.42bis/MNP5 is only to provide the lowest cost
  60. > solution for a full V.42bis/MNP5 featuresd modem. The idea is to provide a cost
  61. > benefit to the end user - it is not a scam, it is the 'real thing'. 
  62.  
  63. Excuse me, but the idea behind offering a product is to _succeed_in_the_
  64. _market_. Obviously a singel-chip modem core is very attractive to modem
  65. manufacturers. This may result in end products with an increased
  66. performance/cost ratio, and finally it _may_ benefit to the end user.
  67. However, this is the consequence not the initiative.
  68.  
  69. > BTW, The ZOOM modems I have seen indicate the V.42bis/MNP5 is "RPI Based" - 
  70. > perhaps the person selling it to you should have made that clear.
  71.  
  72. This did not happen to me; I don't remember who reported this. But it
  73. clearly demonstrates my point: These modems are sold as fully capable of
  74. MNP/LAPM/V.42bis. The average modem buyer certainly has an idea what to
  75. expect from MNP etc. On the other hand "RPI-based" is widely unknown and
  76. very counterintuitive to most user's expectations. This is why I will
  77. continue to spread information about RPI as a WARNING!
  78.  
  79. I already received requests by concerned users how to use the RPI driver
  80. with their favorite non-RPI-sensitive DOS (!) comms application. These
  81. people were tricked into thinking they'd buy a full MNP/V.42bis modem
  82. only to find out that they can't use this important feature in their
  83. environment. Pardon the language but on behalf of those users I'm
  84. _pissed_off_.
  85.  
  86. Rockwell could have forseen the result of their RPI chipset. However, I
  87. doubt that licensing RPI technology explicitely forces a modem vendor to
  88. plainly state that the resulting product is only able to deliver its
  89. claimed performance with the supplied software driver. If Rockwell care
  90. as much about end user satisfaction as implied by their Product Manager
  91. they should consider insisting on such an agreement.
  92.  
  93. > Tony Zuccarino       
  94. > Product Manager
  95. > Rockwell International
  96.  
  97. BTW, please see my signature for the correct spelling of my name.
  98.  
  99. -- 
  100. Christian "naddy" Weisgerber, Germany           naddy@mips.ruessel.sub.org
  101.