Hey Mark,
>
>
> Hey all,
>
> We're having a hard time with a PM-3 on a CT1. All of our
> others PM3's are on PRIs, and we've had very few problems with them.
> Unfortunately, we're upgrading to PM3's at some of our other locations
> where PRIs are not available, so I'd like to get the problems
> resolved. At this point, I'm not sure if it's a PM problem or a phone
> line problem, so any help would be *greatly* appreciated!
>
> The Situation
>
> A PM3, with 3 10 modem cards. ComOS version 3.5.1b20. The lines
> are FSX loop start (ESF, B8ZS). I'd prefer to have wink start
> from what I've read in the list, but phone companies,
> tariffs... don't get me started on that ;-)!
>
> The Problem
>
> Customer busy signals, rings with no answers, no rings, and great
> difficulty in general connecting even when there are *many* ports
> open.
>
> Supporting Information
>
> First, from what I've read, wink start is preferable in the
> C. T1's (but for financial reasons this isn't available to
> us).
>
> Secondly, there looks to be some strangeness in our modems. We
> have 30 (m0 though m19, and m30 through m39 -- I'll probably never
> figure out the numbering convention). They all show good except
> for m18 and m18, which show DOWN. I'm not sure if the modems will
> show down only when they're broken, or maybe the lines are bad --
> any insight here would be appreciated.
The modems are numbered 0-9 on each card, and each card is numbered 0-5
depending on which slot the card is in. If you look at the back of the
chassis (or is that the front ;), top left is slot 0 and bottom right is
slot 5. So, m30 is modem 0 in slot 3 which is bottom left :). Now, we
currently determine whether a card is an 8 or 10 modem card during
initialization -- if the modem fails to self test, then it's 'down' if
it happens to be modem 8 or 9, then it's probably an 8 port card. If
you do a 'sho mo' you'll notice a gap of 2 after we condense the list
which leaves you with just what you really need to see -- the appropriate
number of modems on each card. Since 'm18' is down, you may have to
confirm whether it really is there or not and whether it's bad. To do
this:
set console
set debug mdp-max on
set m18 off
set m18 on
hopefully, you'll get meaningful results. Take a closer look at that
card. Are there other modems that are 'down'? If so, try 'off/on' against
those. Pay special attention to 'sho mo'. If you're watching closely,
you might catch the modem list actually being compressed from say a list
of 10 modems (our initial guess) on the card to maybe 8 modems (the actual
amount). Don't forget that our modems are in a pool, so that ideally
you always will have another available modem for the next call.
>
> The really strange thing, though, is what the modems claim to be
> doing. I have modems that claim to be attached to ports that are
> in fact idle. I also have modems that claim to be attached to
> ports that *other* modems are in fact attached to (as shown be a
> show all). For example:
>
>
>
> pm3-bky-1> show m30
> State: ACTIVE
> Active Port: S2
> ...
>
> pm3-bky-1> show m8
> State: ACTIVE
> Active Port: S2
> ...
>
> ...where a show all show s2 to be attached to m8, not m30.
>
>
Well, as it was explained by engineering to me recently, what needs
to be determined, is whether or not the DSP detected loss of carrier
(since this basic signalling strategy of following DCD was carried over
from the PM2's when attached to an external analog modem) and it didn't
tell the next layer up in the ComOS, or whether ComOS missed the event
from the DSP (with the older DSP's, I'll bet that it is the former).
You're right about foreign exchange vs. wink start -- wink start is nice
(including the ability to debug it), since there are clearly identifiable
state changes in a call including full handshakes with the switch. FXS
at this point depends entirely on the DSP to monitor carrier. We've
built in some fancy footwork (read: timers) to deal with what you are
seeing above, but we've moved onto newer DSP's, so it would really be tough
to finish off your particular issue at this point, until you're 'Flex'able
:). For all I know, the K56 cards are the ticket (we just don't have the
luxury of your specific environment to test in of course).
> Also, the lines appear to be pretty dirty, but that's hard to be
> sure of. In 20 days of uptime, the one T1 has taken CRC errors
> (92), Sync errors (88), and Bipolar errors (65992). The other T1
> is a bit worse than that. Now, it doesn't look good, but those
> errors tally fast when a line goes down, so it *could* be that the
> line went down for a while and the line took all of those errors
> at once.
This is correct and a little unnerving too, keep an eye on it. I've
seen one instance with a CT1 that was improved, by simply adjusting the
line loss to a different level and improving circuit grounding. To me
that means we've improved the signal-to-noise ratio, but I'm still
trying to figure out all the magic that those line techs from the
co-operating telco's can do. In this example, the customer dropped
from the +2db range to the -15db range (use 'sho line0' to see what
we're detecting).
>
> We're running 2.5.1b20 because we were told that this "fixes" the busy
> problem with CT1's, but that's not what we're seeing!
>
If you are willing to camp on the console, then I'd be interested
in seeing the results from:
set console
set debug clock on
set debug mdp-events on
then, when that funky deal happens send me the details and I'll see
if I can determine whether the dsp or comos missed the event.
> Thanks in advance.
>
> --Mark
>
Regards..Todd
-- E. Todd Taylor Livingston Enterprises Inc. Phone: (800) 458-9966 Support Engineer 4464 Willow Road Fax: (510) 737-2110 todd@livingston.com Pleasanton, CA 94588 http://www.livingston.com/