TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Paul Edwards
from: Bill Grimsley
date: 1996-04-05 07:24:32
subject: USR 28.8 Modems

Paul, at 10:55 on Apr 04 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.

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.

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

Because the "retrains granted" works in reverse to the above; if
the remote requests a retrain, and the USR agrees.  Not my problem if you
don't know how to interpret the stats.

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.

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

Then why list it as a purported USR bug?  That's just being dishonest.

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.

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

Missing the point completely, as usual.  Again, it ISN'T a USR problem.

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?  

PE> That's what echos are for.

And if you'd bothered reading the manual, or the readme which comes with
each SDL, you'd have realised that yourself.

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.

PE> Yeah, yeah, heard it all from MBE + Digicom.  No thanks.  BFN.  Paul.

Back to impersonating an ostrich, are you?

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