| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | netcomm m34f problems |
PE> However, I can tell you that the x'91'/x'11' come in up PE> to 3-6 seconds after the CONNECT message, and I doubt any PE> S-register will give such a massive delay in negotiating EC. On a Rockwell, with multiline result codes, you normally see on an incoming call the CARRIER message come up first, then a distinct pause before you see the CONNECT message with the LAPM stuff. The pause is clearly the V.42 negotiation of the error correction protocol etc, that uses that string of bytes you list at the top. PE> I wonder, could the problem be this: Rather doubtful. PE> 1. We get a 28800 connect on a noisy line. PE> 2. We get a lot of noise on the line, so PE> the modems decide to retrain immediately You shouldnt be getting a full retrain at all, these modern protocols allow transparent speed shifting WITHOUT a full retrain. PE> 3. It takes more than 0.75 seconds for the retrain to happen And thats part of the reason that full retrains arent used, they are rather slow. PE> 4. By then, the time has expired for a V42 connection. Even then, the modem should have enough sense to realise its been doing that stuff and not just mindlessly time out the V42 when its been otherwise occupied with fiddling with the carrier. AND it shouldnt need to do a full retrain anyway, it just did one to get the initial connect. And if cant be bursts of noise either, or else Bill wouldnt be getting such dismal handshaking results with Courier/M34F. Its most unlikely that he gets a burst of noise in the initial connect seconds on some many calls in a row. @EOT: ---* Origin: afswlw rjfilepwq (3:711/934.2) SEEN-BY: 711/809 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™.