[j-nsp] interpreting 10Gb interface "PCS statistics" values
Wojciech Janiszewski
wojciech.janiszewski at gmail.com
Fri Oct 21 14:42:13 EDT 2016
Hi David,
I'd say it's a number of seconds with high error rate or errored blocks. In
other words it doesn't show the number of errors but the number of seconds
during which errors were detected.
Regards,
Wojciech
21.10.2016 20:08 "David B Funk" <dbfunk at engineering.uiowa.edu> napisał(a):
> 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{
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list