[j-nsp] interpreting 10Gb interface "PCS statistics" values
David B Funk
dbfunk at engineering.uiowa.edu
Fri Oct 21 14:07:37 EDT 2016
Thanks guys but this isn't what I was asking.
The optical power is similar (within a few tenths of a dBm) at my end, down by 3
dBm at the far end of the link that is having issues (-6.23 dBm as opposed
to -3.73 dBm) but not enough to explain what I'm seeing.
The big question I have is: What does "30 Seconds" mean for an attribute that by
description of the docs is supposed to be number of PCS blocks with invalid Sync
headers?
Particularly when the guy on the Cisco at the other end says his error counters
are going up like crazy (and packets are being dropped) while the stats my end
stays constant at "30 Seconds".
What does that mean?
The particularly frustrating thing is that data streams are dropping packets (EG
iperf3 showing retries and seriously degraded performance) but none of the
interface stats are showing any values that indicate an issue other than that
"30 Seconds".
Can anybody tell me what "30 Seconds" means (in the context of an error
counter)?
On Fri, 21 Oct 2016, Christopher Costa wrote:
> 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&u
> tm_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
> ∆○×□
>
>
--
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{
More information about the juniper-nsp
mailing list