TIP: Click on subject to list as thread! ANSI
echo: aust_modem
to: Paul Edwards
from: Rod Speed
date: 1996-03-04 10:34:28
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™.