Subject: (usr-tc) Code Violation Errors

From: Jim Johnson <[email-masked]>
Date: Fri, 01 Jun 2001 21:35:13 +0000

Recently, in preparation for a telco switchover, we have been testing a
new phone company and currently we have three PRIs up.

About a week ago, we start getting numerous reports of disconnect
problems, so I started looking at this problem and I am a bit
frustrated.

Of course, the phone company monitored the circuits and declared
everything fine on their end.

The only thing that I am seeing is a small number (0 to 100) of Code
Violation errors in each 15 minute interval when I look at the Near End
Current Intervals.

>From looking at the stats, these errors initially were only showing up
on the third PRI, so we went and powered down the chassis and moved the
circuits around to make sure it wasn't the equipment.

However, today I am seeing these errors on all the PRI's.

What would cause these errors and what should I look at from here?

TIA,

Jim

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 01 Jun 2001 22:06:30 +0000

Also sprach Jim Johnson

>What would cause these errors and what should I look at from here?

Line Coding generally refers to AMI and/or B8ZS.  You might have your
equipment set up for B8ZS and some piece of equipment in the transport
between you and their switch (or the switch itself) might be set for
AMI...it only takes one piece of equipment being set wrong to cause
these.

The best way to test this is to run an all-0's pattern over a
loopback'ed line.

AMI and B8ZS are intended to maintain 1's density on a T1, so running
all-0's over it will cause the coding mechanisms in AMI and B8ZS to be
used very frequently.  If a piece of equipment in the transmission path
is set to AMI when it should be B8ZS, you'll see line coding errors rack
up quickly.

This all assumes, of course, that you have some piece of equipment
capable of running Bit Error Rate Testing (BERT).  The DSPs do have some
limited capabilities in this area themselves, but they're not the
easiest thing to work with.

If you've got a cisco t1 card (with integrated csu/dsu), they can often
do BERT...as can some stand-alone CSU/DSU's.  Of course, if you have
access to a T-berd, then you've got it made in the shade.  :)

I use a port on our PA-MC-8T1 to do BERT when I need it, FWIW.

If this isn't your problem...well...I might be able to come up with
other explanations, but not off the top of my head.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Jim Johnson <[email-masked]>
Date: Fri, 01 Jun 2001 22:26:22 +0000

Thanks.  I guess I should request that a telco tech go out with a T-BERD
and check the lines for us to resolve this.

I am curious though, if there were a piece of equipment set for AMI
coding in the circuit, wouldn't that inject either a near constant
amount of errors and wouldn't it be a very large number of these Path
Code Violations within a 15 min period?  I am seeing 15 minute intervals
with no errors, some with 2 or 3 and then a few with 60 or 70 errors
within the interval.

Jim

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 01 Jun 2001 23:12:06 +0000

Also sprach Jim Johnson
>Thanks.  I guess I should request that a telco tech go out with a
>T-BERD and check the lines for us to resolve this.

>Code Violations within a 15 min period?  I am seeing 15 minute
>intervals with no errors, some with 2 or 3 and then a few with 60 or 70
>errors within the interval.

No.  Keep in mind that AMI and B8ZS serve to maintain 1's density on the
circuit.  If the data that's flowing over the circuit would maintain 1's
density without any of the line coding "tricks" that AMI and B8ZS uses,
then those mechanisms don't get triggered, the data is basically sent
over raw, and no line code violations would be seens.  The only time
that you would see line code violations would be when there would be a
timeslot on the T1 that is all 0's, then one of the mechanisms (either
basic AMI, or B8ZS) would kick in, and possibly mangle one or the other
as they conflict.

There is an idle pattern that T1's use on channels that aren't in use (I
don't know the pattern off the top of my head, but I do know that its
not all 0's), so if the circuit is completely idle, it shouldn't trigger
line code problems.  u-law voice encoding, and v.90 pcm encoding don't
ever generate all 0's either (if I remember correctly), so the only time
you should ever see all 0's is when you're dealing with ISDN data calls
(and then it may only be when they are running at 64kbps).

Now then...I'm definitely *not* a telco engineer, so take everything I'm
saying here with a grain of salt...I'm sure inaccuracies could be found.
:)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-