Real Time Ascend Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Ascend Disconnect Performance
Thanks Will,
Of these three codes, the 185/60 is the only one that made it through
authentication. This is the code that results from a user session that
just dropped in the middle of a session. It could be a bad/slow connection
but all the user sees is a message saying that "you have been disconnected,
do you want to reconnect".
I started getting complaints that the calling modem would occasionally not
hear the modem tone from the NAS. In talking with Ascend, they stated that
this problem was being addressed. Ascend stated that the 185/31 and 10/31
both result for the same reason (the modems not being able to hear the tone
of the other modem) but differ in which end hangs up first. Ascend cannot
guarantee that all these codes will go away with the fix installed but most
of them should, hopefully, go away.
All our modems are either the XIRCOM Realport or Megahertz 56kb flashed to
V.90.
I appreciate your feedback... good info!
Mitch
-------------
Original Text
From: "willp2" <willp2@dreamscape.com>, on 3/21/99 7:47 PM:
To: SMTP@DC2@OCC[<ascend-users@bungi.com>]
Mitchel:
Are you including calls that never made it to authentication?
We keep two sets of logs- one for calls that completed authentication, and
a
"failed" log of calls that never made it past authentication. The
difference is
that the failed calls have no userid in the stop record.
The codes roughly translate into:
185/31 is: RemoteEndHungUp / Waiting for DCD (Carrier)
10/31 is: NoCarrierDetectedEver / Waiting for DCD (Carrier)
185/60 is: RemoteEndHungUp / LAN session up
To generate each of these:
185/31: call the modem pool from a regular phone and hang up.
10/31: dial up with a modem. pick up the phone while it is training and
hold
down the "1" button.
185/60: connect with PPP with a modem. then pull the phone cord out of the
back
of the modem while surfing. this sometimes gives a 185/70 (hung up/LCP in
starting state) or a 185/66 (hung up/CCP in open state). If you have
"Software
Compression" enabled in Win9x DUN and MS-Stac link compression enabled in
the
ascend, you'll usually see 185/66 when you pull the phone cord. Disable
software compression in Win9x DUN to see the 185/60 (hung up/lan session
up).
The connect progress is only showing the latest state change in the PPP
session
(or FR, or whatever.)
Now, what is happening when users get these kinds of disconnect codes when
they
dial up with their normal modems, I haven't a clue. The last time I went
to a
computer show (lots of vendors and local computer companies hawking their
wares), I saw literally hundreds of el-cheapo modems with no brand names
that
were simply labelled "56k modem. $25". I'd be willing to bet that a lot of
these el-cheapo's have trouble connecting. Add in the percent of people
whose
phone line is more than 3 miles from their CO, or who have about 20 phones,
an
answering machine, caller-id boxes in every room, and cordless phones all
on one
line, and I'd expect at the _least_ 5% of all calls to fail in a given day.
Now, the interesting number I got out of our logs of connections that
failed
(never made it past authentication) is that almost exactly 50% of failed
calls
reported a modem speed, and the rest did not. In other words, of the calls
that
did not complete authentication, almost exactly 50% of those reported a
modem
speed, the rest did not. Is this what is seen elsewhere?
-Will
-----Original Message-----
From: Mitchell Arnone <mitchell.arnone@occ.treas.gov>
To: @x400hub.net.treas.gov
<":@mailhub-1.net.treas.gov:owner-ascend-users"@max.bungi.com>;
ascend-users@bungi.com <ascend-users@bungi.com>
Date: Sunday, March 21, 1999 2:43 AM
Subject: Re: (ASCEND) Ascend Disconnect Performance
>I would call the 185/31, 10/31 and 185/60 as bad codes. In my example
that
>would work out to be 16%. During Jan and Feb of this year, this total was
>even higher.
>
>Mitch
>-------------
>Original Text
>From: "Mike Tancsa" <mike@sentex.net>, on 3/20/99 9:35 AM:
>To: SMTP@DC2@OCC[<ascend-users@bungi.com>]
>
>On 19 Mar 1999 10:09:10 -0500, in sentex.lists.ascend you wrote:
>
>>The percentages I mentioned represent only those two disconnects. The
>>normal disconnect Cause for the Ascend TNT is cause 45 and progress 60
>(for
>>Windows 95). Our disconnects of this type averages only 60 to 70
percent.
>
>>The rest are mostly 45/65, 11/60, 185/60, 185/31, 10/31.
>>
>>So far for the month of March, we are averaging 3.82% 10/31, 5.65% 185/31,
>>8.65% 45/65, 9% 185/60 and 60.22% 45/60. These statistics are really not
>>the greatest but we don't know how they compare to other sites using the
>>same type of equipment and facilities (we have 11 PRI circuits plugged
>into
>>our TNTs).
>
>What percetage of those cause codes do you consider 'bad' ? For the PM3,
>somewhere between 0-9% I would call bad modem code on the PM3
>
> ---Mike
>
>
>>e.g. here is one PM3 for a month.
>>
>> normal 90.48% 30314/33502
>> "User Request - Call Circuit Closed" 8.07% 2703/33502
>> "Lost Carrier" 0.82% 276/33502
>> "User Error - PPP NCP Active to Request" 0.60% 201/33502
>>"Service Unavailable-Failed to detect V.42 remote" 0.01% 5/33502
>> "User Error - LAPM negotiation timeout" 0.01% 2/33502
>>"Port Error - Exceeded LAPM retransmission limit" 0.00% 1/33502
>>
>>
>> ---Mike
>>Mike Tancsa (mdtancsa@sentex.net)
>>Sentex Communications Corp,
>>Waterloo, Ontario, Canada
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>