Paul, at 20:43 on Apr 02 1996, you wrote to Bill Grimsley...

PE> 3. Modem is initiating a retrain straight after each connect,
PE> even with V32bis modems.  I would expect that the initial
PE> negotiation would have figured that out, no need for a retrain
PE> on every single bloody call.  Yet the ATI6 does not show that
PE> a retrain was requested.

BTW, you are obviously unaware of how those stats work.  They won't show a
retrain as being requested unless it's also been granted at the other end. 
This was discussed some months ago in USR_Modems.

BG> As far as I can recall, you were never able to prove that this was 
BG> happening with any modem other than Rod's Supra, and nobody else ever 

PE> That is correct.

BG> reported similar instances, despite this peculiarity being discussed at 

PE> That is correct.

BG> great length in Aust_Modems.  Insufficient data to blame the Courier, IMO.

PE> I wasn't actually blaming the Courier. 

Oh crap.  You used it as just another excuse to heap shit on the Courier.

PE> It is up to USR to ask Rod to call their US BBS at a particular time of the 
PE> day, so that they can do a datascope trace. 

Nope, it's not up to USR to fix it at all.  If the problem is peculiar to
Supra, then it's THEIR problem, and it's up to them, to fix it.

BG> Not a bug.  Refer the explanation in my previous message WRT the necessity 
BG> of using different defaults for certain S registers with some SDLs.

PE> Ok, I'll take your word for that.  Should have mentioned it at the
PE> time and I would have verified it.  More than one ROM at that
"feature".

Why should I have said anything?  You were too busy bashing USRs to pay any
attention, so I thought I'd lt you dig a really deep hole before pushing
the dirt in on top of you.

BG> Dave Hatch saw this once, too.  Because it's so rare (I've never seen it 
BG> happen with any of my USRs), I'd tend to put it down to a major line 
BG> glitch.

PE> 21600/2400?  Only half the line is bad???

Grow up, Paul.  If a line glitch has trashed the stats, NONE of them can be trusted.

BG> Lots of weird shit happened with the 25-01-1995 SDL.  Far too many problems 
BG> with it for it to be coincidental IMO.  Probably fucked ROM code.

PE> Another problem-in-waiting.

Nope, you just trash that particular code release, and use one of the many
later versions, simple as that.  Problem solved.

BG> I saw another very similar stats display not all that long ago, and general 
BG> consensus was that the line had suffered a major glitch.

PE> Even if the line gets hit by a nuclear strike, the modem should not
PE> defy the laws of physics.

If it scrambles the ROM, you don't know what it's likely to report.  The
modem didn't defy the laws of physics, the stats did.

BG> Rod told me that the failure rate was never 30%, but I should wait for 
BG> verification anyway.  Any idea if that was the 25-01-1995 ROM code?

PE> No, that was with the 1995-07-05 code.  And also, that is a 
PE> problem-in-waiting because I was unable to reproduce it on a later
PE> trial, so needed more testing of that, which I was not able to do.

Couldn't have possibly been operator error, could it?  :)

Like I said, most of those problems were one-offs that couldn't be
reproduced, so you'll forgive me if I look upon your complaints as
USR-bashing.

--- Msgedsq/2 3.20