Rod, at 09:49 on May 20 1996, you wrote to Bill Grimsley...

BG> You'll have seen Pete's retraction by now, where he clearly
BG> states that he connected with LAPM, but not V.42bis.

RS> I have in fact seen him say that he STILL got a /NONE connect between
RS> a pair of Couriers and that that other one was a different session.

Where did you see that?  I've just checked all of his messages in
USR_Modems, and apart from the first one where he claims the connect was
/NONE (which he later retracted), he's said no such thing.  Have a quote...

======================================================================
Date:   Sat May 18 1996 10:11:52
From:   Peter McGrath
To:     Bill Grimsley
Subj:   Problem Connects
Attr:   recvd scanned 
USR_MODEMS                     -------------------------------

Hi Bill,

PM> I noticed a connect a while ago between two identical Couriers with
PM> no error correction. 

BG> Interesting, I thought I was the only one with this problem,
BG> although it's never happened when connecting with another USR.

Seems I was a bit confused here, in fact my problem was that COMPRESSION
wasn't negotiated not error correction. This was a once off and while I'd
like to know why it happened, I guess it can't be used as evidence that
the error correction negotiotion in the couriers may be faulty.

regards, Peter.

-!- Maximus/2 3.01
 ! Origin: the OMEN  *  +61 2 437 5629  *  Sydney, Australia  * (3:711/957)
===========================================================================

If you have any evidence to the contrary, I'd rather like to see it.

BG> True.  That ordinarily wouldn't have mattered, but as this discussion
BG> is about one specific problem, it does change the context considerably.

RS> Nope, because when its with the SAME modem at each end, its the absolute
RS> proof that that modem has a problem, coz its the ONLY modem present.

Well, it would have been proof if the problem had actually occurred.  Pity
it didn't though.  There was no V.42bis negotiated (not no EC at all), and
the consensus now is that the remote had compression disabled for some
reason.

RS> Or that the USR code is defective, both the M34F and
RS> Viper are NOT doing anything out of spec at all in the
RS> V42 protocol negotiation phase, and that there are slight
RS> differences between them, WHICH ARE PERFECTLY LEGAL

BG> What LEGAL differences in the ITU recommendations do you mean?

RS> I meant the modems themselves, not the recommendations. 

Then why didn't you explicitly say so?  :)

RS> Say the design of the line interface circuitry. Still within spec to 
RS> qualify as V34 but not identical.

Oh sure, but we already know, for example, that the Austel-approved models
are purportedly quite different in the LI area, yet this has never really
appeared to have caused problems.  If anything, the non-Austels seem to
work better.

RS> Or say the transmit level, again, within the legal range.

And with V.34 specifically, that shouldn't be a problem at all.  The
protocol is designed to transparently allow for things like that.

BG> Apart from the various optional bits, ALL modems should be created
BG> equal when it comes to the mandatory stuff.  Obviously they're not.

RS> Quite a bit has a range thats still qualifys as within spec.

Which kind of defeats the purpose of set-in-stone specs, doesn't it?

RS> the defect in the USR code gives a different failure rate between them.

BG> You'd just LOVE the USR code to be proved defective, wouldn't you?  :)

RS> I dont give a damn basically. ALL code is GUARANTEED to have defects.

I think you'll find that Paul would disagree with that comment.  :)

RS> This is the phase where we identify warts and excise them.

Sure, I have no argument with that at all.  Part of the problem could just
as easily be somebody's personal interpretation of the recommendations too.

RS> Until you actually determine that the M34F and the Viper are actually
RS> doing something that V42 says they should not do, you have no basis
RS> whatever for proclaiming that the Netcom is at fault at all on that.

BG> I'm claiming nothing,

RS> Fraid you did, particularly on whether the Netcom is the cause
RS> of the very high rate of /NONE connects when called by a Courier.

Whatever you may think of USR's Joe Frankiewicz, the fact still remains
that it is he who is mainly responsible for the SDL code in the Couriers,
and given his comments re the poor implementation of the 3429 symbol rate
in some modems (chipset related, but fixable in the controller code) I
still strongly suspect that the NetComm code is deficient in this area (and
quite possibly others), and the fact that it only happens with Paul's M34F
makes it even more evident.

RS> I've binned the rest, its just going around in circles, going nowhere.

Feeling a bit outnumbered by the USR FRZs, are we?  :)

Regards, Bill

--- Msgedsq/2 3.20