Re: (PM) UPDATE: Fast Busies on PM3

Jeffrey Stevison (jstevison@emeraldsurf.net)
Fri, 05 Feb 1999 09:30:31 -0600

Well I'm having the same problem. I just reported it to Lucent tech
support. They seemed to be puzzled also, almost as if they had not
heard of this. The told me to ask my customers at what time of day is
this occurring? How long has this been happening? Have you noticed any
changes once connected? I have experienced this myself. I have 1 PRI
line. When dialing in I get a fast busy. Hang up and immediately call
back and get on. Check the port usage and there may only be 9 ports in
use. Usually a low number of ports are in use when I experience this.
I've had 3 customers so far report the problem.

I have 2 10 port cards and 1 8 port card. They told me to swap the
position of the 10 port cards. Monitor the PRI line for errors (which
has been totally clean for 13 days now).

After trying this for 2 days they will debug and log my box.

Jason Hatch wrote:
>
> I have been working a little bit with Livingston technical support about
> my fast busy problem. I've also come across an undocumented command that
> can be used to display statistics about B channels (see below).
>
> As I explained in my 3 previous posts, we have been getting a problem with
> fast busies being issued to customers on a 4 PM3 huntgroup when all ports
> are not in use. On one occasion, my telco was able to track the problem
> down to the 6th (5th if you start at 0) B channel on my 3rd PRI (1st PRI
> in second PM3). Basically, when a call came down that channel, the PM
> would refuse the call. No modems are stuck in ADMIN, DOWN or ERROR state.
> I had the telco "busy-out" that B channel and the problem went away for a
> while.
>
> We had this fast busy problem again last night. I noticed that port S22
> was not accepting calls, and rebooted the portmaster. Port S22 still did
> not accept any calls. What I didn't realize at the time, was that this was
> probably due to the fact that they busied out B channel 5, which I later
> learned (see below) was assigned to S22. However, while searaching for the
> "req channel not avail" error that "show s22" was listing in it's
> "Disconnect" field, I came across an interesting thread from Sept 98. That
> thread identified port S22 as being the main culprit in a lot of problems.
> Please see http://www.dataman.nl/showport.lp?i=442106&s=pEQhHIGxhGjnX8op .
>
> There are a lot of other random occurrences of disconnect problems in the
> portmaster-users archive. I'm suprised that Livingston seemed so unaware
> of this when I called.
>
> While working with Livingston, I came across an UNDOCUMENTED command that
> may be beneficial to this list. Please note that I know very little about
> the various parameters of this command and neither did the tech support
> person. The command I used was to show B channel statistics, but there are
> many parameters and no-doubt many of them are not meant to be messed with.
> Therefore, please use this at YOUR OWN RISK as you might be able to screw
> something up if you experiment with other settings.
>
> The PM3 has a DSU framing chip that was made in Munich, Germany. The
> command that references this chip is called "munich" :
>
> pm3_1> munich
> usage: munich channels
> usage: munich intr
> usage: munich intrq
> usage: munich recv <portname | all>
> usage: munich spec
> usage: munich stat <portname | all>
> usage: munich statd
> usage: munich stats [<dev_n>]
> usage: munich statt <portname | all>
> usage: munich statr <portname | all>
> usage: munich timeslots
> usage: munich xmit <portname | all>
> pm3_1>
>
> There are two parameters that I have been introduced to. They are "munich
> stats" and "munich channels". They basically show information about B
> channels and which ports are attached to which B channels, as well as
> various other receive/transmit stats. I don't recommend messing with
> anything else.
>
> Example:
>
> To show channels on Line0:
>
> pm3_2> munich channels 0
> ch port dv readq xmitq cur_rd cur_td
> 0 S6 0 0- 5 0- 0 391c2c 000000
> 1 S3 0 2- 1 0- 0 39206c 000000
> 2 S11 0 3- 2 0- 0 39249c 000000
> 3 S19 0 3- 2 0- 0 3928bc 000000
> 4 S9 0 2- 1 0- 0 392ccc 000000
> 5 S22 0 0- 0 0- 0 000000 000000
> 6 S7 0 4- 3 0- 0 39352c 000000
> 7 S18 0 3- 2 0- 0 39393c 000000
> 8 S4 0 1- 0 0- 0 393d3c 000000
> 9 S16 0 3- 2 0- 0 39417c 000000
> 10 S1 0 4- 3 0- 0 3945ac 000000
> 11 S21 0 3- 2 0- 0 3949bc 000000
> 12 S2 0 5- 4 0- 0 394dfc 000000
> 13 S20 0 2- 1 0- 0 3951ec 000000
> 14 S15 0 1- 0 0- 0 3955fc 000000
> 15 S17 0 1- 0 0- 0 395a1c 000000
> 16 S10 0 4- 3 0- 0 395e6c 000000
> 17 S0 0 2- 1 0- 0 39626c 000000
> 18 S8 0 0- 5 26-27 39666c 3969b0
> 19 S12 0 2- 1 20-20 396aac 396d7c
> 20 S5 0 0- 5 0- 0 396eac 000000
> 21 S13 0 0- 5 0- 0 3972cc 000000
> 22 S14 0 4- 3 0- 0 39772c 000000
> 23 D0 0 3- 2 3- 4 397b3c 397d3c
>
> Note that S22, my problem port, has 0's going across the statistical
> fields. This is probably because my telco still has it "busied out", so I
> haven't seen what a port looks like when it's messing up. Regardless, with
> this problem, it is useful to be able to see which B channels are getting
> which ports. The "munich stats" command also looks useful for
> troubleshooting:
>
> pm3_2> munich stats 0
> | Transmit| Receive | td td
> prt dv ch cur_rd cur_td |state good| good bad | idle cnt
> S6 0 0 391c2c 000000 | Off 0| 0 0 | 0 0
> S3 0 1 39206c 000000 | Off 0| 0 0 | 0 0
> S11 0 2 39249c 000000 | Off 0| 8 0 | 0 0
> S19 0 3 3928bc 000000 | Off 0| 6 0 | 0 0
> S9 0 4 392ccc 000000 | Off 0| 3 0 | 0 32
> S22 0 5 000000 000000 | Off 0| 0 0 | 0 64
> S7 0 6 39352c 000000 | Off 0| 2 0 | 0 0
> S18 0 7 39393c 000000 | Off 0| 0 0 | 0 0
> S4 0 8 393d3c 000000 | Off 0| 1 0 | 0 0
> S16 0 9 39417c 000000 | Off 0| 3 0 | 0 0
> S1 0 10 3945ac 000000 | Off 0| 0 0 | 0 0
> S21 0 11 3949bc 000000 | Off 0| 0 0 | 0 0
> S2 0 12 394dfc 000000 | Off 0| 0 0 | 0 0
> S20 0 13 3951ec 000000 | Off 0| 0 0 | 0 32
> S15 0 14 3955fc 000000 | Off 0| 0 0 | 0 0
> S17 0 15 395a1c 000000 | Off 0| 0 0 | 0 0
> S10 0 16 395e6c 000000 | Off 0| 10 0 | 0 0
> S0 0 17 39626c 000000 | Off 0| 0 0 | 0 0
> S8 0 18 39666c 3969b0 | Off 3b9| 6e 0 | 0 31
> S12 0 19 396aac 396d7c | Off 933| 157 20 | 7 32
> S5 0 20 396eac 000000 | Off 0| 1 0 | 0 0
> S13 0 21 3972cc 000000 | Off 0| 1 0 | 0 0
> S14 0 22 39772c 000000 | Off 0| 0 0 | 0 0
> D0 0 23 397b4c 397e20 | Act 18d7| 18c4 0 | 0 31
>
> Again, aside from obvious things, I know very little about this command.
> Hopefully Lucent will get with the program and document it, as I was told
> that up until recently, only engineers knew about this. Again, use this at
> your own risk.
>
> -Jason
>
> oooooo o o oo o o--o | J Hatch "You toucha my SPARC, I breaka you face."
> oo o o oo oo o--o | System Administrator, B e r k s h i r e N e t
> - - - -- - - | email: zone@berkshire.net phone: (413) 442-7805
> oo o o oo o o | web: http://www.BERKSHIRE.net/
> oooooo o o oo o o--o | Cdomain Web based WHOIS: http://www.CDOMAIN.com
>
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe portmaster-users' in the body of the message.
> Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>