[j-nsp] interpreting 10Gb interface "PCS statistics" values

Christopher Costa ccosta at gaikai.com
Fri Oct 21 12:55:26 EDT 2016


Here's my notes from a jtac review about these a couple years ago:




[pcs] encoding is continually transmitting to keep the line in sync. The
PCS layer is directly below the MAC layer so for MX, it’s on the MIC. PCS
errors can be caused by anything MIC or lower, i.e. transceiver, fiber,
line equipment, etc.




PCS functionality:

===================

IEEE 802.3ae 10GbE interfaces use a 64B/66B encoder/decoder in the PHY-PCS
(Physical Coding Sub layer) to allow reasonable clock recovery and
facilitate alignment of the data stream at the receiver.

As the scheme name suggests, 64 bits of data on the MAC layer are
transmitted as a 66-bit code block on the PHY layer, which realizes easier
clock/timing synchronization. A 66-bit code block contains a 2-bit Sync.
Header + 8 octets data/control field.

If the Sync. header is '01', the 8 octets are entirely data.

If the Sync. header is '10', an 8-bit Type field follows, plus 56 bits of
data/control field.

The 8 octets data/control field is scrambled by using a self-synchronous
scrambler to achieve complete DC-balance on the serial line.

PCS statistics displays PCS fault conditions by checking valid Sync.
headers received with every 66 bits interval, so that we can monitor 10Gbps
high speed transmission line quality.

If the 64B/66B receiver does not detect the 2-bit Sync.

Header with regular 66-bit interval and it estimates the high BER (Bit
Error Rate of >10^-4), PCS statistics will report a problem.

PCS statistics :

================

- "Bit errors" indicates the number of PCS blocks with invalid Sync headers.

- "Errored blocks" indicates the number of PCS blocks with a valid Sync.
header but invalid block format.


On Fri, Oct 21, 2016 at 9:37 AM, Michael Carey <mcarey at kinber.org> wrote:

> David,
>
> When I've seen PCS statistical errors before, it pointed to either a
> failing optic that needed replaced in our MX or a drastic change in optical
> light levels caused by an OSP fiber issue.  How do your "show interface
> diagnostic optic" levels look?
>
> On Wed, Oct 19, 2016 at 7:40 PM, David B Funk <
> dbfunk at engineering.uiowa.edu>
> wrote:
>
> > I've got a couple of 10Gig-eth interfaces (xe- on MX480) of which I'm
> > trying to interpret the "PCS statistics" values.
> >
> > One of them is pretty steady at:
> >
> >   PCS statistics                      Seconds
> >     Bit errors                             4
> >     Errored blocks                         4
> >
> > The other one seems to vary with the values ranging from 10 to 70.
> > EG:
> >
> >   PCS statistics                      Seconds
> >     Bit errors                            61
> >     Errored blocks                        69
> >
> > The second interface will will trigger a number of error conditions at
> the
> > other end which terminates in a Cisco router with out showing any error
> > conditions at my end (EG BPDU Error: None, MAC-REWRITE Error: None,
> > CRC/Align errors 0, FIFO errors 0, etc..) During some of these times I'll
> > see significant packet loss and others see minimal problems.
> >
> > According to Juniper docs the PCS statistics should mean:
> >
> >  PCS statistics
> >   (10-Gigabit Ethernet interfaces) Displays Physical Coding Sublayer
> (PCS)
> > fault
> >   conditions from the WAN PHY or the LAN PHY device.
> >
> >     Bit errors—High bit error rate. Indicates the number of bit errors
> > when the
> >       PCS receiver is operating in normal mode.
> >     Errored blocks—Loss of block lock. The number of errored blocks when
> > PCS
> >       receiver is operating in normal mode.
> >
> > But I don't know how to interpret a value of "16 seconds" with that
> > definition.
> > Can anybody shed some light on what those numbers mean.
> >
> > Thanks.
> >
> >
> > --
> > Dave Funk                                  University of Iowa
> > <dbfunk (at) engineering.uiowa.edu>        College of Engineering
> > 319/335-5751   FAX: 319/384-0549           1256 Seamans Center
> > Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
> > #include <std_disclaimer.h>
> > Better is not better, 'standard' is better. B{
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
> --
>
>
> [image: photo]
> *Michael Carey*
> Director of Operations, KINBER
> 717-963-7490
> <717-963-7490?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_
> content=&utm_campaign=signature>
> | 814-777-5027
> <814-777-5027?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_
> content=&utm_campaign=signature>
> | mcarey at kinber.org | 5775 Allentown Blvd., Suite 101, Harrisburg, PA
> 17112
> <https://www.facebook.com/Keystone-Initiative-for-
> Network-Based-Education-and-Research-188743104566075/?utm_
> source=WiseStamp&utm_medium=email&utm_term=&utm_content=&
> utm_campaign=signature>
> <http://www.twitter.com/kinber?utm_source=WiseStamp&
> utm_medium=email&utm_term=&utm_content=&utm_campaign=signature>
> <https://www.linkedin.com/company/kinber-keystone-
> initiative-for-network-based-education-and-research-?utm_
> source=WiseStamp&utm_medium=email&utm_term=&utm_content=&
> utm_campaign=signature>
> <https://vimeo.com/kinber/videos?utm_source=WiseStamp&
> utm_medium=email&utm_term=&utm_content=&utm_campaign=signature>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Chris Costa
∆○×□


More information about the juniper-nsp mailing list