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

Rod, at 11:30 on May 17 1996, you wrote to Bill Grimsley...

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 line
BG> quality from the equation, but Peter's was just a
BG> 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.

You'll have seen Pete's retraction by now, where he clearly states that he
connected with LAPM, but not V.42bis.  I've never even heard of failure to
negotiate compression before, so I'd hazard a guess that the remote may
have actually had it disabled for some reason.

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

Irrelevant now that we know the story.

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.

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

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 Viper are NOT doing
RS> anything out of spec at all in the V42 protocol negotiation phase, and
RS> that there are slight differences between them, WHICH ARE PERFECTLY LEGAL

What LEGAL differences in the ITU recommendations do you mean?  Apart from
the various optional bits, ALL modems should be created equal when it comes
to the mandatory stuff.  Obviously though, they're not.

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

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

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.

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

RS> All you KNOW is that its makes the /NONE connects much more common
RS> when called by a USR. But that heaps of other modems call the Netcom
RS> without getting any /NONE connects at all, ever.

By the same token, I have also mentioned several times before (and had said
comments either ignored or deleted completely) that apart from Paul's board
(regardless of the modem he uses), I have NEVER had a non-EC connect with
ANY other modem anywhere, in either Australia or the US.  Not once, not
ever.

BG> or that both the USR AND the M34F have less than perfect
BG> V.42 code, and/or that the Viper's is slightly better.

RS> Thats possible, but well down the list of possibilitys, particularly
RS> when some modems can call both without EVER seeing a /NONE connect.

Or that I can call others with the same perfect result (Paul aside)...

RS> And you CANT just change things, like say what does V42 in a modem.

No, but you can certainly disable things like the V.42 detect phase, which
just happens to solve the problem with Paul anyway (28800/ARQ today).

RS> Its these more complex fault situations that really
RS> sorts out those who can do it from those who cant.

BG> It helps to have the right diagnostic tools too.  Most (and I) don't.

RS> Yes, but its also possible carefully analyse the evidence and
RS> reach useful conclusions even when you dont have the diagnostic tools.

In some cases, sure.  Not in others though.

RS> And that is indeed part of why these are much harder than
RS> VCRs where you would normally have had the diagnostic tools or
RS> can readily just change bits to see if thats where the problem is.

Oi, I've NEVER been a "board-changer"!  Sure, some tend to take
the easy way out, particularly these days, but I've always repaired
everything (apart from PCs of course) to component level, and can't even
remember having changed a part unless I knew for a fact that it was
actually fucked.  You forget that I work on my own, and am not in the
financial position of being to buy a $60 IC simply on spec, not when I
can't take it back if that wasn't the problem.

BG> It may also be relevant that these 28800/NONEs
BG> have only happened with Rockwells,

RS> I doubt it, more likely that its just that they are much more common,
RS> particularly when it has been seen between a pair of Couriers too.

It hasn't, so the original comment is still valid.

BG> but I'm not prepared to suggest that there's an inherent problem
BG> with their chipset, when it could just as easily be USR's problem.

RS> If fact HAS to be if seen between a pair of Couriers,

Pity it wasn't (bet that hurts too).  :)

RS> and clearly can be fixed with a Sportster rom change.

To Rockwells, sure.

BG> Dunno, but consider this.  Is it not possible that
BG> because the USR uses generic DSP technology, they are
BG> in a far better position to adhere to the ITU specs to
BG> the letter, and that Rockwell may have strayed a touch?

RS> Nope.

It's definitely not possible, eh?  Yours is a completely silly comment with
no basis in fact, and speaks volumes for your attitude towards USR.

RS> Makes no difference if you use a masked rom for the code except
RS> in the sense that its easier to change and fix a wart with a soft modem.

Of course it makes a difference.  If you buy a Rockwell with a buggy
chipset (and those who bought any of the first 19 revisions most certainly
did), tough shit, there's fuck all you can do about it.  Not so with the
Courier series, where ALL of the code can be replaced in around 60 seconds.

BG> It wouldn't be the first time, you know.  Look at the
BG> V.FC debacle, where Rockwell wrote the specs, USR followed
BG> them to the letter, yet Rockwell kept changing them!

RS> Well, that was the story from USR. USR has a HELL of a capacity
RS> for blaming EVERYTHING on someone else. 

Oh crap.  Somebody in Oz_modems once actually posted a message from the
Rockwell Corporation themselves, which specifically stated that there were
several updates to the V.FC code in their earlier revision chipsets.

RS> I havent EVER seen them actually come out and say 'sorry, we fucked that up 
RS> pretty badly, this SDL fixes that fuckup', they ALWAYS blame it on someone 
RS> else if they can possibly find someone else to blame.

Says nothing useful about Rockwell's diabolical V.FC fuckups though, does it?

BG> I'm not suggesting that's true, but it IS a possibility.

RS> Not when its seen between a pair of USRs Bill, there is NO ONE
RS> that you can claim is following the ITU specs worse than you are.

I wish you'd learn to speak correct English, as I have no idea what that is
supposed to mean, but suffice it to say that the problem has NOT been seen
between 2 Couriers after all, so your claim is crap.

RS> AND *YOU* yourself saw HEAPS of those with the Sportster with the
RS> less than the best rom calling Pauls Courier. The aint no one who can
RS> possibly have fucked up the ITU specs but USR in that case is there ?

In THAT case, there was a definite improvement when calling others with
dodgy lines, but you can't absolutely claim that USR didn't simply upgrade
their code to cope with inherent problems with the Rockwell code.  In the
absence of any definitive evidence, you'd be mad if you did.

BG> If it was Rockwell, I'd say we were fucked, but at least I feel that
BG> with USR, we at least have a chance that something will be done about it.

RS> We'll see.

6 new SDLs in 18 months proves to me that they ARE doing something
positive.  How many FREE chipset upgrades have Rockwell offered during the
same time?

Regards, Bill

--- Msgedsq/2 3.20
* Origin: Logan City, SEQ +61 7 3200 8606 MO (3:640/305.9)
SEEN-BY: 640/305 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™.