100G, input errors and/or transceiver issues

Tue Jul 20 11:48:52 UTC 2021

You could also enable FEC on the link. This will remove any errors until
the link quality is really far gone.

Regards

Baldur

man. 19. jul. 2021 20.06 skrev Graham Johnston <johnston.grahamj at gmail.com>:

> Thank you all for the consensus. What I hear from you is that 100G takes
> more care to operate error free, as compared to 10G, which wasn't
> surprising to me. Also, that generally, we should be able to operate
> without errors, or certainly less than I'm currently observing, and that
> connector and transceiver interface cleanliness is our first likely point
> of investigation.
>
> Thanks to all who responded.
>
> On Mon, 19 Jul 2021 at 12:58, Jared Mauch <jared at puck.nether.net> wrote:
>
>>
>>
>> > On Jul 19, 2021, at 1:50 PM, Saku Ytti <saku at ytti.fi> wrote:
>> >
>> > On Mon, 19 Jul 2021 at 20:19, Graham Johnston
>> > <johnston.grahamj at gmail.com> wrote:
>> >
>> >> I don't at this point have long term data collection compiled for the
>> issues that we've faced. That said, we have two 100G transport links that
>> have a regular background level of input errors at ranges that hover
>> between 0.00055 to 0.00383 PPS on one link, and none to 0.00135 PPS (that
>> jumped to 0.03943 PPS over the weekend). The range is often directionally
>> associated rather than variable
>> >
>> > On typical 100G link we do not get single FCS error in a typical day.
>> > However Ethernet spec still allows very high error rate of 10**-12. So
>> > 1 error per 1Tb (b not B). I.e. 1 error per 10s, or 0.1PPS would be
>> > in-spec. We see much better performance to this and vendors generally
>> > accept lower error rates as legitimate errors.
>> >
>>
>> I will confirm my experience with this at $dayjob as well.  We see
>> interfaces with no errors over much longer periods of time inclusive of
>> several of the technology options.  If you are seeing errors, there’s
>> likely something wrong like unclean fiber or bad optic/linecard etc.
>>
>> - Jared
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210720/18d84643/attachment.html>