| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.