Re: (ASCEND) Ascend Disconnect Performance

["willp2" <willp2@dreamscape.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>