| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | USR 28.8 Modems |
PE> 3. Modem is initiating a retrain straight PE> after each connect, even with V32bis modems. Thats overstating it, we dont have any evidence for retrains EXCEPT when the caller is a V32bis modem. PE> I would expect that the initial negotiation would have figured that out, Yes, particularly with a V32bis call which is already at its maximum speed. It does appear however that the Courier is doing that to try to see if V32terbo is possible, and likely thats the only way to see. PE> no need for a retrain on every single bloody call. We dont know it does. PE> Yet the ATI6 does not show that a retrain was requested. Yeah, definite glitch there, presumably the Courier doesnt count it because its actually a test to see if V32terbo is possible. Dunno that you can call this a true bug, more a wart that may well be unavoidable with with the rather gross kludge that V32terbo is. So there is a sense in which you are stuck with it if you want V32terbo. BG> As far as I can recall, you were never able to prove that BG> this was happening with any modem other than Rod's Supra, BG> and nobody else ever reported similar instances, despite this BG> peculiarity being discussed at great length in Aust_Modems. All we ever proved is that Ian never saw a retrain. We proved nothing useful at all about V32bis modems calling Couriers in general. BG> Insufficient data to blame the Courier, IMO. Crap. We know it still happens with the Supra configured to never request a retrain, so the Courier must be requesting one. And since disabling V32terbo eliminates it, and you can see the logic in a retrain and V32terbo, when there aint any other way to see if V32terbo, its pretty clear its a problem in the Courier. Corse the main problem is that V32terbo is such a crude kludge that its not possible to elegantly coexist with the older protocols out in the field in the much cleaner way that V34 obviously can do. PE> 6. A Spirit Thunder is getting connects with me at 2400 bps far PE> more often than 19200. 1200 bps connects too. Actually, this PE> problem occurred with the 1995-07-18 Supervisor Date and one from PE> 1995-01-25, and has gone away with 1995-07-05 ROMs. It seems to PE> have not occurred too many times with the 1995-07-18 ROMs either. BG> Could be either modem at fault here, although my gut BG> reaction is that it's the Thunder which is the problem, Thats coz you are a zealot |-) Clearly the specific SDL changes the stats. BG> especially when one considers that David D has 5 or 6 BG> Thunder callers who connect without any difficulties at all. He has immaculate lines. Proves no more than that deficiency is seen on less than immaculate lines with some SDLs. Dave also never say your atrocious handshaking failure rate and we KNOW that that was due to a combination of an indifferent line and less that good code in the USR. PE> 7. USR to USR connect failed due to a retrain failure. Also, USR to USR is PE> showing 21600/2400 as the connect rate. This was done with the 1995-07-18 PE> ROMs and being fairly rare has not yet happened with the new ROMs. BG> Dave Hatch saw this once, too. Dave saw it a lot more than once, tho it appears to be a problem with one of his lines. We wont know for sure until a fix makes it go forever. BG> Because it's so rare (I've never seen it happen with any of my USRs), Surely you can grasp that this proves as little as your tests from CHH which turned out to prove sweet fuck all about how a USR would behave on your home line with all but the latest Sportster rom ? BG> I'd tend to put it down to a major line glitch. You dont have the evidence to be able to do that. Even 'tend' It has to be put in the bin of not enough evidence to say much. PE> 8. Failed to connect to Hayes modem at all. Very weird sounds PE> coming out. No problem when I was using a Spirit. This actually PE> happened with an older revision of the ROMs (1995-01-25), and PE> cannot confirm at this stage whether it still exists because PE> the modem was taken offline so that I could connect. BG> It's impossible to say who's at fault here. Maybe, your experience calling Rockwells on the CHH BBS from your house tho does make you wonder about the USR code. Producing that effect with some lines. @EOT: ---* Origin: afswlw rjfilepwq (3:711/934.2) SEEN-BY: 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™.