From: Richard Genoud <firstname.lastname@example.org> To: Willy Tarreau <email@example.com>, Richard Genoud <firstname.lastname@example.org> Cc: email@example.com, Thomas Petazzoni <firstname.lastname@example.org>, Antoine Tenart <email@example.com>, Gregory CLEMENT <firstname.lastname@example.org>, Yelena Krivosheev <email@example.com>, Maxime Chevallier <firstname.lastname@example.org>, Nicolas Ferre <email@example.com>, firstname.lastname@example.org, Andrew Lunn <email@example.com> Subject: Re: CRC errors between mvneta and macb Date: Tue, 23 Oct 2018 08:56:07 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20181022163429.GA22826@1wt.eu> Le 22/10/2018 à 18:34, Willy Tarreau a écrit : > On Mon, Oct 22, 2018 at 05:15:21PM +0200, Richard Genoud wrote: >> After analyzing the ethernet frame on the Davicom PHY's output (pin >> TX+), I find out that the FCS errors occurs when the ethernet preamble >> is longer than 56bits. (something like 58 or 60 bits) >> >> To say this in another way, instead of having 28 times 1-0 followed by >> the SFD (10101011), I see 29 or 30 times 1-0 followed by the SFD. >> (sometimes 29, sometimes 30) >> >> >> Should a longer preamble be considered as an FCS error ? It seems a >> little harsh since the point of the preamble is to synchronize the frame. > > That indeed seems a bit strange considering that you're not supposed to > know what is before the preamble so it would very well contain random > noise looking a lot like alteranted bits. > >> I don't know what the 802.3 standard says about that. > > Just found it :-) > > https://www.trincoll.edu/Academics/MajorsAndMinors/Engineering/Documents/IEEE%20Standard%20for%20Ethernet.pdf > > Page 132, #184.108.40.206 : > > The DTE is required to supply at least 56 bits of preamble in > order to satisfy system requirements. System components consume > preamble bits in order to perform their functions. The number > of preamble bits sourced ensures an adequate number of bits are > provided to each system component to correctly implement its > function. > > So that totally makes sense since the purpose is to enable signal > detection at the hardware leve, hence the problem definitely is on > the receiver in your case. > > Willy > Great ! Thanks ! I'll check on the Marvell side Richard
next prev parent reply other threads:[~2018-10-23 7:03 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-19 15:15 Richard Genoud 2018-10-19 15:44 ` Willy Tarreau 2018-10-22 6:51 ` Richard Genoud 2018-10-22 15:15 ` Richard Genoud 2018-10-22 16:34 ` Willy Tarreau 2018-10-23 6:56 ` Richard Genoud [this message] 2018-10-22 18:19 ` Andrew Lunn 2018-10-23 6:58 ` Richard Genoud 2018-10-23 12:37 ` Richard Genoud
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: CRC errors between mvneta and macb' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).