BG> Looks more like defective code now, but until I'd
BG> heard about others with the same problem, I was
BG> loathe to blame USR based on just one sample (mine).

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.

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

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

BG> I'm also not convinced that the M34F is completely blameless
BG> either, given that it happened FAR less frequently with Paul's Viper.

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

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

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

ALL that shows in a proof sense is that it VARYS in rate.
We already know that the rate varys with the LINE too, you
dud line being heaps worse with a USR V32bis modem calling
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,

Or that the USR code is defective, both the M34F and Viper are NOT doing
anything out of spec at all in the V42 protocol negotiation phase, and
that there are slight differences between them, WHICH ARE PERFECTLY LEGAL
and the defect in the USR code gives a different failure rate between them.

JUST like you saw with a V32bis Sportster calling a
Spirit, where the line the Sportster is used on clearly
makes a HELL of a difference to the rate of /NONE connects.

Until you actually determine that the M34F and the Viper are actually
doing something that V42 says they should not do, you have no basis
whatever for proclaiming that the Netcom is at fault at all on that.
All you KNOW is that its makes the /NONE connects much more common
when called by a USR. But that heaps of other modems call the Netcom
without getting any /NONE connects at all, 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.

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

RS> Dial up comms has always been absolutely notorious for being
RS> very difficult to deal with because of the vast combination
RS> of modems at each end, combined with a quite bizarre variety
RS> of different detail in the local loop at each end alone.

BG> Far too many variables, I know.

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

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.

Yes, but its also possible carefully analyse the evidence and
reach useful conclusions even when you dont have the diagnostic
tools. And that is indeed part of why these are much harder than
VCRs where you would normally have had the diagnostic tools or
can readily just change bits to see if thats where the problem is.

BG> and after a while you tend to see the same
BG> faults cropping up with great regularity.

RS> Yes, but these complex fault situations with dial up comms aint like that.

BG> Perhaps not as frequently, but most, if not all modems have
BG> their own particular quirks which you soon learn to work around.

Well, they arent that major a part of real world modem problems.

RS> A deficiency in the USR which they obviously know
RS> how to fix if the latest Sportster rom did so.

BG> Unless it was accidental.

RS> Yeah, could have said that more carefully, either know
RS> already or can analyse and work out why if it was accidental.

RS> Doesnt require Netcom to do anything and since the Viper
RS> exhibits it too, the best place to fix it is in the Courier SDL.

BG> Assuming that the fault is USR-specific, of course.

Well, its clearly fixable in the USR coz the Sportster rom did so.

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

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

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.

If fact HAS to be if seen between a pair of Couriers,
and clearly can be fixed with a Sportster rom change.

BG> Otherwise, that fix would surely have been
BG> carried over to the later Courier SDLs.

RS> Dunno, I have seen a quite disturbing variance on the service tone
RS> detection variability between Courier SDLs and Sportster roms.

BG> Only on US models though.  The Austel ones worked just fine in that regard.

The point tho is that if they get the disturbing variability in
the US code, they aint doing the version control very well at all.
An improvement should just carry thru to all the new stuff. It doesnt.

RS> Looks very much like USR isnt actually administering that fix stuff well.

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?

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

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!

Well, that was the story from USR. USR has a HELL of a capacity
for blaming EVERYTHING on someone else. I havent EVER seen them
actually come out and say 'sorry, we fucked that up pretty badly,
this SDL fixes that fuckup', they ALWAYS blame it on someone else
if they can possibly find someone else to blame.

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

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

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

BG> but given the other recent reports about this in
BG> the USR_Modems echo, it may also now be adequate.

RS> Yeah, looks like it. Corse they will probably just ignore
RS> it like they have done the ATY11 problem which is completely
RS> reproducible at will and they can test themselves anytime too.

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.

We'll see.
@EOT:

---