Richard Town wrote the following to Wes Newell, and I quote (in part):
   RT>> Why do you think that the "problem is probably in the Zoom"?
 WN-> Because I went through at least 5 of the early 14.4's and lost
 WN-> probably 100 hours of sleep trying to get the early Rockwell chipsets
 WN-> working on my line, which  wasn't very good at all. The modem would
 RT> The point is that USR was late into the V32bis arena, preferring to
 RT> try and force their proprietary HST at 14k4 instead.
Forval, Digicom, USR were the first vendors to have V.32bis modems on the 
market, and they did so _before_ the recommendation was officially ratified. 
Where do you dream this stuff up at?
 RT> They tried it on with V.FC, but that was a V42bis glitch if memory 
 RT> serves, after being late there too preferring to hold on to their 
 RT> proprietary 21k6 and then go to V34 directly.  They, as I've 
 RT> proved, did do it at V34+/V34Plus, and have definately definately 
 RT> done it in UK code at x2 denying any "foreign" V34 calls at all.
 RT> Add to this the decision to stay out of 56k Open Forum, go to fax
 RT> Class2.0 before ratification
Wrong. Class 2.0 was adopted before it was ever implented in a USR product. 
 RT> and not offer Class2,
Class 2 was _never_ adopted, and is not in Rockwell offerings any longer.
 RT> refuse to recognise extended V42 commands...
From : Stephen Worthington
To   : All                                 
Subj : Known bugs in Rockwell-based 14.4k modems?                            
-----------------------------------------------------------------------------
From: stephen@inisant.actrix.gen.nz (Stephen Worthington)
Newsgroups: comp.dcom.modems
Subject: Known bugs in Rockwell-based 14.4k modems?
Organization: Digi-Tech Communications Limited, Wellington, New Zealand
Message-ID: 
Date: Tue, 06 Dec 1994 02:11:42 +0000
In article , Ed Hall  wrote:
>Tony Zuccarino (tony.zuccarino@nb.rockwell.com) wrote:
>: In article , arnim@atlantis.actrix.gen.nz (Arnim
>: Littek) wrote:
>
>: > Yes, there is a bug in the Rockwell implementation of V.42.  At
>: > startup, when V.42 is required to send an "EC", the Rockwell V.42
>: > implementation sends an "EM".
>
>: Not at all. See explanation below.
>:       . . . .
>: Response from Rockwell firmware engineering -
>
>: :"Upon detection of the ODP, the Answerer sends 5 iterations of the 
>: :MDP, each of which is as follows:
>: :
>: :(E) and (M) separated by 8 to 16 ones.
>: :
>: :After sending the MDP, the Answerer sends the ADP, 
>: :per Sec 7.2.1.3 of the V.42, then waits for a response from the
>: :originator......""
>: :
>: :The above is an extract of ANNEX E - MNP Extended Services
>: :
>: :So, we do that because we have extended services. Extended services can
>: :be disabled with AT-K0."
>
>So, in other words, an answering Rockwell modem will respond to the ODP
>with five cycles of "EM" followed by n cycles of "EC"?  And the problem
>is that the originating modem is getting freaked out by the five "EM"'s
>and not properly receiving the subsequent "EC"'s?
>
>I can see how some modem designers might have assumed that the only
>proper responses to an ODP are either an immediate ADP or silence, but
>that's an awfully poor assumption; I really couldn't say this was
>Rockwell's problem.
>
>What do other modems with MNP Extended Services do?  Do the same modems
>which have problems with Rockwell modems also have problems with them?
>
>This V.42 problem doesn't seem related to the reputed V.42 "protocol error"
>involved in V.FC.  I'd love to see a chapter and verse (well, clause and
>subclause) citing of this purported bug.
>
>      -Ed Hall
>      edhall@rand.org
OK, I re-read the relevant section of the revised V.42 specification
today, and there are a couple of little ambiguities in the wording
about answer data patterns (ADPs).  Surprise, surprise!!!
There seem to be two possible readings of the way you should wait for
an ADP:
  1) As soon as you see a valid ADP (sufficient repeats of the
     pattern), act on that pattern.
  2) Wait a full T400 timeout (default 750 ms according to another
     section of V.42), and then act on the pattern seen.
Number 1) is what all sensible modem software programmers have chosen
to do (myself included).  The reasons are that waiting for a full
timeout of T400 before responding to an ADP makes for a slow startup
for the modem and seems to defeat part of the purpose of having ODPs
and ADPs in the first place.
Two valid ADPs are defined in V.42:
   EC = go to V.42
   Enull = abandon V.42 (and fall back to another protocol if your
           modem wants to try that)
Nowhere does V.42 suggest that an ADP can start off in one pattern
and change to another.  What does seem to be suggested is that you
should wait for a recognisable pattern repeated sufficient times to
be valid, then act on it.  The ambiguity here is that a pattern of E
followed by another character is obviously supposed to be meaningful,
and hence should be acted upon, but V.42 only defines the two ADPs
above, and another interpretation of V.42 might say that anything
other than one of the two patterns is garbage and pattern matching
should continue until one of the two is seen (or T400 times out).
So my reading of what Rockwell have done in implementing an EM
pattern followed by an EC pattern is that they seem to have taken the
path of saying that, unless the modem is capable of Extended MNP, it
should not recognise the EM pattern as a pattern but treat it as
garbage and go on pattern matching.  Of course, I and many others had
already implemented it the other way, and the EM pattern is
recognised as a pattern and causes immediate fallback out of V.42. If
Rockwell or whoever wrote the Extended MNP specification had
researched the current modems out in the real world, they would have
found this and done Extended MNP some other way...
And I also believe that the mixed patterns are fundamentally in
breach of the idea of the ADPs in another way: they reduce the number
of repetitions of EC avaialble for recognition under bad line
conditions and therefore make a bad startup where the wrong protocol
(or no protocol) is selected a much greater probability.
I really do wish people would be more careful:
   1) ITU-T specifications often have much larger holes than this in
      them, or are so impossible to comprehend that you just plain
      make mistakes interpreting them.
   2) A little research into what is actually in use in the real
      world is *really* a good idea (alpha and beta testing
      anyone???)
=============
 RT> ... their lovelyness goes on and on
From: JACK PETTY                      Read: NO
Subj: Re: Modem chipsets            Status: PUBLIC MSG
----------------------------------------------------------------------------
From: Petty@ralvm29.VNET.IBM.COM (Jack Petty)
Date: Mon, 8 Jun 92 07:46:11 EDT
Newsgroups: comp.dcom.modems
Subject: Re: Modem chipsets
In  tnixon@hayes.com writes:
>I think you'll find that in comparative tests, most of these 
>non-Rockwell modems perform better than the Rockwell-based modems 
>(but, again, the Rockwell-based modems perform satisfactorily for most 
>users on typical phone lines).
>
Toby,
When you get around to providing details, be sure to specify which Rockwell 
data pump was being tested. There are major telco performance differences 
among Rockwell's data pumps.  For example, I tested three different versions 
of the R9696 series data pumps.  The first one did not have any phase jitter
cancellation, the second one did not have any phase jitter cancellation
below 50 Hz, and the third one finally had a good implementation
of phase jitter cancellation.
Also, I have been told the RC 144 series of data pumps had a telco
performance problem that has been fixed starting with Rockwell's May
production run.
Jack Petty
============
Try again Richard, but get some _facts_ first.
Regards....
Craig
aka: cford@ix.netcom.com
   : craig.ford@2001.conchbbs.com
--- timEd/2 1.10+
---------------