USR V.34 Sportsters line drop with Motorola Codex & Other Modems

USR V.34 Sportsters line drop with Motorola Codex & Other Modems

Post by A » Mon, 08 May 1995 04:00:00






>: >I operate a pool of some 170 rack mounted Motorla Codex 3267 V.34 modems
>: >(rom versions 7.1 & 7.5) for the University of Alberta. Users dialing in
>: >with USR Sportster V.34 modems (both old & new rom versions) are
>: >encountering line drop problems some 5 or so minutes into almost every
>: >connection they make to the pool.
>: >I get various ati6 disconnect reasons from the Sportsters (loss of
>: >carrier, loop loss disconnect, GSTN cleardown).
>: >The Codex end always reports "Training timer expired (V.32/V.32bis)"
>: >- admittedly weird.
>: These sound like V.42 negotiation failures during retraining.
>Nonsense; V.42 isn't renegotiated after retrains.  V.42 has nothing to
>do with retrains, and in fact is independent of the particular modulation
>it is implemented over: V.34, V.32bis, V.22bis, or whatever.
>A retrain timeout means that the modems didn't complete a retrain within
>the time allotted.  Each phase of the retrain process (there are three,
>exactly the same as phases 2 through 4 of the original connection
>process) has a recovery procedure should one of the signals involved not
>be detected correctly or in time.  Essentially what happens is that
>the failing phase is repeated.  If the connection is bad enough, or
>failures are generated by some other cause, it is possible for retrain
>to continue indefinitely.  Most modems will call a halt to this process
>if it goes on long enough (either based on time or number of attempts
>or both) and disconnect.

I have just recently heard of this "Death Spiral"  and just recently been on
this group, but independently I have explored this problem and wonder if
this problem is something else, and only a Scope could tell if this is the
case.

Rockwell states that " V.FC (TM) probes at 68 frequencies and uses 50 Hz
spacing, while V.34 uses 21 frequencies with 150 Hz spacing. However, V.FC
(TM) analyzes the probe data results in the same way as V.34. So, V.FC (TM)
uses three times more line probing frequencies than V.34.  The channel probe
only occurs in the initial train for both technologies."

Note that they say that the "channel probe only occurs in the initial
train."  Since most V.34 modems have V.fc code within, then what if, for
whatever the reason, one of the modems  goes into the "initial train" for
the wrong standard (V.34 or V.fc).  In other words, the two modems are
handshaking on different frequencies, and this causes the "Downward Death
Spiral."

Yes, Rockwell states that " While V.FC (TM) has the same retrain and
speed switching procedures as V.34, it also has a semi-seamless rate change.
 The semi-seamless rate change has the advantage of not interrupting the
data modulation.  Retrains by the V.FC (TM) data pump require the same time
as a V.34 retrain. In the past, there have been differences in host
controller implementations that have increased the retrain time under
certain conditions, but they have been corrected.

Note they say, "In the past, there have been differences in host
controller....."

But, what if, somehow, one of  these modems which have conflicts switches to
the "intial" train at the opposite configuration (V.34 vs V.fc).

Further, at the ISP that I am using with my Zoom V.fc, I have found that for
some reason I can not use the LAP-M protocol unless I want disconnects with
the USR modems.  So, I have to use the MNP protocol to avoid this problem.  
Out of 16 modems, there is only one modem which I get disconnected on now,
and this line always connects at a much lower modem speed;  hence, maybe bad
telephone line or modem.

In my situation with the Zoom V.fc, I use

(1) No  Retrains                        %E    Default
(2)  Run MNP                    \N5
(3)  No compression             S46=136
(4)  MNP connect only           S36=4
Verbose result code             S95=127

Thus, I use:
AT&C1&D2S95=127S36=4\N5S46=136

and get this:

Quote:>CARRIER 24000
>PROTOCOL: ALT
>COMPRESSION: CLASS 5
>CONNECT 24000/ARQ

Footnote:  On Zoom, the default for retrains is "turned-off," but before I
started changing the AT strings around, I noticed that from time to time my
modem was "whinning" during a session and then "Ka-boom," a disconnect.  In
other words, even though the retrain was turned off by default, it APPEARED
that the modem was handshaking during the session.  Since I do not have a
Scope,  I have concluded that retraining was going on even though it should
not have occured.  Further, the LAP-M protocol APPEARS to be related to this
problem.

I have not explored this testing phase, but if I would put the %E2 string in
on the MNP protocol, I have a feeling that nothing would happen;  in other
words, no disconnects.  But I have not tried this yet.

In essence, I found that by using the MNP protocol, the disconnects went
away. Of course, check your modem book for the correct AT string, ihmo.

AJ

 
 
 

USR V.34 Sportsters line drop with Motorola Codex & Other Modems

Post by John Garne » Tue, 09 May 1995 04:00:00


|I have just recently heard of this "Death Spiral"  and just recently been on
|this group, but independently I have explored this problem and wonder if
|this problem is something else, and only a Scope could tell if this is the
|case.
|
|Rockwell states that " V.FC (TM) probes at 68 frequencies and uses 50 Hz
|spacing, while V.34 uses 21 frequencies with 150 Hz spacing. However, V.FC
|(TM) analyzes the probe data results in the same way as V.34. So, V.FC (TM)
|uses three times more line probing frequencies than V.34.  The channel probe
|only occurs in the initial train for both technologies."
|
|Note that they say that the "channel probe only occurs in the initial
|train."  Since most V.34 modems have V.fc code within, then what if, for
|whatever the reason, one of the modems  goes into the "initial train" for
|the wrong standard (V.34 or V.fc).  In other words, the two modems are
|handshaking on different frequencies, and this causes the "Downward Death
|Spiral."

I saw this "downward death spirtal" occur between two V.FC USR Sportsters
(neither had the V.34 ROM upgrade).  Your explanation might be accurate
for some pairs of modems but it definitely cannot fully account for the
problem.

-John
--

               World Wide Web: http://www.compbio.caltech.edu/~garnett
"A distributed system is one in which the failure of a computer you didn't
 even know existed can render your own computer unusable." - Leslie Lamport

 
 
 

USR V.34 Sportsters line drop with Motorola Codex & Other Modems

Post by A » Tue, 09 May 1995 04:00:00



>I saw this "downward death spirtal" occur between two V.FC USR Sportsters
>(neither had the V.34 ROM upgrade).  Your explanation might be accurate
>for some pairs of modems but it definitely cannot fully account for the
>problem.
>I saw this "downward death spirtal" occur between two V.FC USR Sportsters
>(neither had the V.34 ROM upgrade).  Your explanation might be accurate
>for some pairs of modems but it definitely cannot fully account for the
>problem.

The ISP here uses USRs.  I use a Zoom, but a week ago, I bought a USR
and tested it for a week.  No problems with USR to USR.

But with the Zoom modem, I must use MNP protocol or get disconnected.

BTW, there is no doubt that when electronic components get hot they
can act differently, but here with this ISP, USR to USR works OK.

AJ

 
 
 

USR V.34 Sportsters line drop with Motorola Codex & Other Modems

Post by Chris Straws » Sat, 13 May 1995 04:00:00



>BTW, there is no doubt that when electronic components get hot they
>can act differently, but here with this ISP, USR to USR works OK.

When I call USR Sportster to USR Sportster I get the Sprial Death
twice as bad since each Sportster will be falling back.  If you call
Sportster to non-Sportster, the problem is not as bad since the
non-Sportster will not be falling back.
 
 
 

1. USR V.34 Sportsters line drop with Motorola Codex 3267s

I operate a pool of some 170 rack mounted Motorla Codex 3267 V.34 modems
(rom versions 7.1 & 7.5) for the University of Alberta. Users dialing in
with USR Sportster V.34 modems (both old & new rom versions) are
encountering line drop problems some 5 or so minutes into almost every
connection they make to the pool.

I get various ati6 disconnect reasons from the Sportsters (loss of
carrier, loop loss disconnect, GSTN cleardown).

The Codex end always reports "Training timer expired (V.32/V.32bis)"
- admittedly weird.

I've tried various things as suggested by USR tech support & others (none
of which have had any effect):
   at&f1s54=96s56=16
   at&f1s54=120
   at&f1s10=255
   at&f1&n13

No other V.34 modem user is having this problem (Supras work fine).

In one particular damning series of tests over about 5 hours today, where
nothing but the calling modem & init strings were changed,
- the Sportster dropped the connection 3 times with the connections of 13
minutes, 15 minutes, & 15 minutes,
- a Motorola Power 28.8 stayed connected at 28,800 for 1 hour (till I
disconnected it),
- the Motorola Power 28.8 stayed connected at 28,800 for 30 minutes (till
I disconnected it),
- the Sportster dropped the line in 6 minutes, 5 minutes, & 6 minutes.
So every Sportster connection I've made today has dropped.

I don't hear any retraining sounds from the Sportsters.

The only thing that works (I think) is at&f1s56=64, which unfortunately
turns off V.34, and forces the connection down to 14,400 bps. This is not
a nice thing to have to do to a 28,800 bps modem.

Any help would be appreciated. Thanks.

2. conference proceedings

3. USR Sportster/Motorola Codex retrain line drop solved

4. Microsoft Internet Directory

5. && MODEMS, MODEMS, MODEMS HIGH SPEED LOW COST V.34 **&&&

6. How to get pageframe.sty to work with LaTeX2e

7. USR Sportster V.34 rate drops

8. View Question: Response View?

9. Motorola Codex 326x should be reference for all others

10. Motorola Power V.34 &/vs. USR Courier V.everything

11. USR Sportster V.34 vs. SupraFax V.34

12. USR Sportster V.34 vs Supra V.34

13. USR Sportster V.34 or Vi.34