TIP: Click on subject to list as thread! ANSI
echo: aust_modem
to: Meng-Shi Lim
from: Dave Hatch
date: 1996-06-24 22:52:08
subject: Fallback limits

On Jun 23 14:28 96, Meng-Shi Lim of 3:635/503 wrote:

ML> -=> Quoting Dave Hatch to Meng-Shi Lim <=-

ML>> Does anyone know what happens if retrain is enabled and fallback is
ML>> DISABLED? Does the modem retrain repeatedly at the initial DCE speed
ML>> until the line gets so bad that carrier is dropped?

DH>> In the case of this fault, (if that's what it is, no guarantees) this
DH>> won't help.  The theory is sound - but the line degradation once
DH>> triggered is much worse than the line would normally be. 
DH>> There's currently a theory (mine) that the calling tones help trigger
DH>> the problem - I have a line with the problem fairly often, and it
DH>> doesn't happen with either low speed modems, or VFC.  I have yet to
DH>> prove that disabling calling tone will avoid the problem, but it
DH>> appears possible. 

(I've since disproved this theory to my dissatisfaction.  I've yet to dream
up another credible theory to take its place.)

DH>> If you're ambitious, could you try disabling the v8 tones prior to
DH>> connect, and report back to us if it helps/fixes/has no effect when
DH>> there's a known bad line session on? 

ML> Calling tone is disabled by default here and there doesn't seem to be
ML> much difference when I enabled it. I wasn't paying much attention when I
ML> tried this so I need to try a few more times I guess. I'm actually not
ML> quite sure what the calling tone is or does. But, this modem sounds like
ML> it is sending an additional and regular noise down the line when it is
ML> waiting for an answer. ie initiate dial->dial tone->tone
dialling->>ringing->BEEP->ringing->BEEP->remote pickup
and answer +/-
ML> beep. My external modem doesn't produce this BEEP after dialling. This
ML> beep is independent of the ring of the remote phone and depending on the
ML> timing of when the remote answers the call, can occur during the
ML> handshake period. Depending on the phase of the handshake, this beep can
ML> occasionally stuff up the whole process. Is this the calling tone?

Yes.

ML>> Another question: on a 28.8k modem, if the connection is made at less
ML>> than 28.8k (eg 21600), can the modem pick up and renegotiate a higher
ML>> speed from this point onwards if the quality of the line improves?

DH>> This is normal operation for a USR.  I commonly connect on one of my
DH>> nearby hub links at 21600, and then happily log 3650 cps transfers
DH>> both ways on that link. It's fairly conservative in connect speed, but
DH>> the fallforward is excellent. 

ML>> (Personally I don't think so but you'll never know). I know that the
ML>> modem can retrain up and down from the connection speed (eg 21600 ->
DH>> 19200 ->>21600) but I'm not sure about the above.

DH>> Your connect speed vis achieved cps later in the call tell the tale.

ML> To my surprise it happened here. I forced a connection at 16800 and after
ML> hanging up, ATI6 reported a 24000 connection. It would be nice if I
ML> could force a 14.4k v34 connection and let the modem retrain upwards
ML> (given that the highest speed handshaking often fails here) but for some
ML> reason the modem always connects at 14.4k with v32bis only, although it is
ML> not uncommon to get a fallback from a higher speed v34 connection to a
ML> 14.4k v34 speed. Can you force a 14.4k v34 on your modem?

I get one regularly to one US site.  Unfortunately, the only way I see
immediately to force a speed would also lock it at that speed, if I
correctly understand the manual.   I agree with your idea completely - just
don't know how to set it up to happen that way.

ML> I mainly use this modem for TCP/IP connection and the CPS is never as
ML> high as a ZMODEM transfer on a BBS. However, Win95's system monitor
ML> gives a dynamic reading of the modem's send/receive CPS and from these
ML> one can get a pretty good indication of whether the modem is falling
ML> back or forward.

Have to look into that - Win95 is intruding more or less on my earstwhile
quiet life..:-)

Regards,
Dave Hatch.

--- Msgedsq 3.20
* Origin: Ministry Support Group (3:711/808)
SEEN-BY: 50/99 620/243 623/630 624/300 625/100 711/401 409 410 413 430 808
SEEN-BY: 711/809 899 932 934 712/515 713/888 714/906 800/1
@PATH: 711/808 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™.