Rod, at 11:41 on May 15 1996, you wrote to Bill Grimsley...

BG> but in the last 2 days, I've seen a reference to one fellow in the US 
BG> having it happen, and now the same thing (albeit only once) with Peter 
BG> McGrath, locally (between Couriers too)

RS> Thats certainly interesting, particularly the between Couriers bit.

Trouble is, it's a one-off, and to suggest that its cause was specifically
a modem problem would be a tad premature, not to mention dangerous. 
Personally, I wouldn't be worrying too much unless it happened again.

RS> There is some evidence that V42 wasnt designed quite as robustly as it
RS> might have been on that error correction capability negotiation and that
RS> if you arent careful, that can bite code that trys to implement it.

Yeah, that's stock answer from USR re these LAPM problems, to disable the
V.42 detect phase (but not V.42 itself).  That seems to do the trick for
just about everybody too, but I haven't tried it yet, because disabling the
3429 symbol rate when calling Paul has had a similar effect.

RS> Clearly, if PARTICULAR rom in a Sportster
RS> fixes that, it must be fixable by USR.

BG> Agreed, but as I said, they may have fluked it unintentionally.

RS> Yep, thats certainly quite possible. Bet they just ignore that
RS> comment you made to them tho, when they should look very closely
RS> at it to see what fluked it and add that to the Courier SDLs too.

Who knows how those people think though?  USR are quite notorious for
appearing to ignore things, then reacting quickly and positively.  An
example that comes to mind is the time that everybody was demanding CID,
and for several months, USR said that they had no plans to introduce it,
then a week later, out comes the new SDL with CID code added.  The same
thing with the SDS drama, nobody from USR would acknowledge that there was
a problem, then bugger me, a month later, a free EPROM update is offered.

I'd like to think that although USR says very little, they are collating
all the available bug-report info from places such as the USR echo, and
quietly working away in order to solve those problems which are
reproducible, at which time they'll simply drop another SDL upon us, right
out of the blue.  It won't be the first time if they do, although one could
also suggest that keeping their customers happy during the interim might
not be such a bad idea either.

RS> Corse thats not trivial if you cant setup the test config that exhibits
RS> the problem. Maybe you should offer to flog them your house, they come
RS> over here and thoroughly massage the Courier code on the spot |-)

The neighbours might be arseholes, but I wouldn't wish yanks upon them.

RS> Boy did you get ONE HELL of a surprise when you used the
RS> Sportster at home with the old rom calling it tho. Which
RS> went away completely when you installed the best rom.

BG> Which also happened to be the one which increased the speed
BG> to 33600, and as the 28800 code also used the 3429 symbol
BG> rate, it can't have been that alone causing the problem.

RS> Yeah, the 3429 symbol rate story looks rather iffy.

I'm starting to suspect that there might actually be two problems (somehow
related) with the V.42 code insofar as disabling the V.42 detect phase will
also solve the /NONE problem, same as disabling the top symbol rate will.

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.

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

BG> I'm also not convinced that the M34F is completely blameless either,
BG> 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.

Dunno, if I connect without EC to an M34F at a 50% rate, but to a Viper
with only 10% failures, it suggests to me that either the USR's code is
completely to blame AND the M34F is incapable of overcoming the problem
half the time, or that both the USR AND the M34F have less than perfect
V.42 code, and/or that the Viper's is slightly better.  From the POV of
determining where the exact problem lies though, I agree that it still says
nothing particularly useful.

BG> I understand testing quite well, Rod.
BG> 18 years of fixing sodding VCRs has seen to that,

RS> Nope, they are far easier, you can change bits.

Is that some sort of highly esoteric pun?  If so, I think I got it.  :)

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.

Far too many variables, I know.

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

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

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.

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

RS> fine, uploads fucked. But this /NONE problem is a classic example
RS> of a very complex fault situation which you really need to know
RS> what you are doing to analyse and come to useful conclusions on.
RS> PARTICULARLY when you cant datascope the protocol negotiation phase.

Agreed.

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 now already
RS> or can analyse and work out why if it was accidental.

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

Assuming that the fault is USR-specific, of course.  It may also be
relevant that these 28800/NONEs have only happened with Rockwells, but I'm
not prepared to suggest that there's an inherent problem with their
chipset, when it could just as easily be USR's problem.

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.

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

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

Dunno, but consider this.  Is it not possible that because the USR uses
generic DSP technology, they are in a far better position to adhere to the
ITU specs to the letter, and that Rockwell may have strayed a touch?  It
wouldn't be the first time, you know.  Look at the V.FC debacle, where
Rockwell wrote the specs, USR followed them to the letter, yet Rockwell
kept changing them!  I'm not suggesting that's true, but it IS a
possibility.

BG> That's still not as large a sample as I'd like,

RS> Sure, if I was the USR person chasing that down, I would
RS> certainly do a few hundred calls first to be quite sure.

True, but my phone bill wouldn't stand that sort of testing.  :)

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.

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

Regards, Bill

--- Msgedsq/2 3.20