TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Bill Grimsley
from: Paul Edwards
date: 1996-04-04 10:55:52
subject: USR 28.8 Modems

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.

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

Then why do they have a retrain requested AND a retrains granted.

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 

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

PE> I wasn't actually blaming the Courier. 

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

Only in the mind of a zealot, Bill.  I presume all my Netcomm bug
reports are just another excuse to heap shit on the Netcomm, right?
Talk about one-eyed cronyism.

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. 

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

Yeah, yeah, heard it all before.  MBE said the same thing about the
Rockwell double-send bug.  Quite pathetic actually.  I didn't expect
USR to be any better than Digicom, and I was right.

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".

BG> Why should I have said anything?  

That's what echos are for.

BG> You were too busy bashing USRs to pay any 
BG> attention, so I thought I'd lt you dig a really deep hole before pushing 

Yeah, yeah, sure Bill.

BG> the dirt in on top of you.

I believe you, Bill, I really do.  That's why you spent so much time
trying to convince me that everyone wanted ATZ to not autobaud right,
quoting any old crap you could find, instead of the one thing that
you claim to be able to easily prove with reference to the SDL docs.
I really really believe you Bill.  Really and truly.

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???

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

If the stats are being trashed, that sounds like a bug in the code.
If USR want to claim that there's no way they can work around that,
then that's fine, I'll accept that.  It's up to them to say something
other than "why don't you try calling England".

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.

BG> If it scrambles the ROM, you don't know what it's likely to report.  The 

ROM doesn't get scrambled, Bill.

BG> modem didn't defy the laws of physics, the stats did.

Then there's a bug in the software.  It's not that difficult a 
concept to grasp, Bill.  Pretend it was a Netcomm we were talking
about, what would you say then.  Hint: "Typical fucked stats of
the Netcomm".

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.

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

Not unless you can tell me what AT command I could possibly have
accidentally typed in.

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

Yeah, yeah, heard it all from MBE + Digicom.  No thanks.  BFN.  Paul.
@EOT:

---
* Origin: X (3:711/934.9)

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™.