TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Bill Grimsley
from: Rod Speed
date: 1996-05-20 09:49:48
subject: failed calls

RS> True, the bulldogs results calling Pauls Netcomm was
RS> interesting, and Petes even more so since its between Couriers.

BG> Yeah, Dave's result more or less eliminates the
BG> line quality from the equation, but Peter's was just
BG> a one-off, and could have been caused by anything at all.

RS> True, but it all adds up to yet more evidence that the USR has a problem.
RS> PARTICULARLY when seen between a pair of Couriers when there cant be any
RS> possibility of the modem at the other end being a non USR at fault.

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

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

RS> Yes, clearly much rarer between a pair of USRs,
RS> BUT this is crucial because ONLY USR code is involved.

BG> Irrelevant now that we know the story.

Nope, the story aint what you are saying now.

RS> Thats another area you never really have grasped, that
RS> RATES dont say anything useful about where the fault lies.

RS> More legalistically I should have said where *A* fault lies.

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

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

BG> Dunno, if I connect without EC to an M34F at a
BG> 50% rate, but to a Viper with only 10% failures,

RS> ALL that shows in a proof sense is that it VARYS in rate.
RS> We already know that the rate varys with the LINE too, you
RS> dud line being heaps worse with a USR V32bis modem calling
RS> a Spirit than anyone elses with the SAME pair of modems.

BG> it suggests to me that either the USR's code is completely to blame
BG> AND the M34F is incapable of overcoming the problem half the time,

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?

I meant the modems themselves, not the recommendations. Say the design of
the line interface circuitry. Still within spec to qualify as V34 but not
identical. Or say the transmit level, again, within the legal range.

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

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

RS> and 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?  :)

I dont give a damn basically. ALL code is GUARANTEED to have defects.
This is the phase where we identify warts and excise them.

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,

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

BG> and have even acknowledged that there may well be a problem in the
BG> Courier code, just as there may well be a problem with the Rockwell
BG> code too.  Neither of us are in a position to prove a damn thing though.

Fraid we are Bill, particularly when its seen between a pair of
USRs and when changing a USR rom eliminates that obscene rate.

I've binned the rest, its just going around in circles, going nowhere.
@EOT:

---
* Origin: afswlw rjfilepwq (3:711/934.2)
SEEN-BY: 711/934
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.