MII SFD detection

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi,

I want to know exactly how the SFD detection algorithm works for MII MAC receiver.
14 answers Last reply
More about detection
  1. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <52053ea0.0407130543.355ced57@posting.google.com>,
    mittal@einfochips.com (mittal patel) wrote:

    > Hi,
    >
    > I want to know exactly how the SFD detection algorithm works for MII MAC
    > receiver.

    SFD detection is completely specified in the IEEE 802.3 standard,
    available free from standards.ieee.org.


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  2. Archived from groups: comp.dcom.lans.ethernet (More info?)

    >
    > > Hi,
    > >
    > > I want to know exactly how the SFD detection algorithm works for MII MAC
    > > receiver.
    >
    > SFD detection is completely specified in the IEEE 802.3 standard,
    > available free from standards.ieee.org.

    Yes, it's given in the 802.3 standard. The PhysicalSignalDecap
    function in the standard says: "receive one bit at a time from the
    physical medium until a valid sfd is detected". But when working at
    the MII interface, 4 bits are received by the MAC at a time. Therefore
    1)Should MAC check 4 bit pattern 101011 or 8 bit pattern 10101011.
    2)If the Preamble is corrupted, should the corrupted preamble ptterns
    be ignored, except the one which is similer to sfd.
    3) what if sfd is corrupted and data contains sfd pattern.
    4)If MAC don't find sfd within first 8 bytes (i.e max(preamble+sfd)),
    should it stop frame collection after the 8 bytes considering sfd
    error.

    Rich, I would really appreciate if you can clear above doubts.
    Thanks in advance,
    Mittal
  3. Archived from groups: comp.dcom.lans.ethernet (More info?)

    "mittal patel" <mittal@einfochips.com> wrote:

    > > > I want to know exactly how the SFD detection algorithm works for
    MII MAC
    > > > receiver.
    > >
    > > SFD detection is completely specified in the IEEE 802.3 standard,
    > > available free from standards.ieee.org.
    >
    > Yes, it's given in the 802.3 standard. The PhysicalSignalDecap
    > function in the standard says: "receive one bit at a time from the
    > physical medium until a valid sfd is detected". But when working at
    > the MII interface, 4 bits are received by the MAC at a time. Therefore
    > 1)Should MAC check 4 bit pattern 101011 or 8 bit pattern 10101011.
    > 2)If the Preamble is corrupted, should the corrupted preamble ptterns
    > be ignored, except the one which is similer to sfd.
    > 3) what if sfd is corrupted and data contains sfd pattern.
    > 4)If MAC don't find sfd within first 8 bytes (i.e max(preamble+sfd)),
    > should it stop frame collection after the 8 bytes considering sfd
    > error.

    Here's my understanding of IEEE 802.3:

    In 10 Mb/s Ethernet, 802.3 paragraph 9.6.1 says that 15 preamble bits
    must be received before search for SFD begins (this is DataRdy state).
    So if the interface was idle at the beginning, then it receives at least
    15 properly alternating preamble bits, then a correct SFD appears, the
    receiver assumes this is the start of a new frame. If this doesn't
    happen, that is, either the at least 15 correct preamble bits did *not*
    follow an idle period, or a correct SFD byte wasn't detected after these
    preamble bits, then the receiver won't assume any frame exists.

    So if the first 41 bits of the 56-bit preamble were corrupted, in
    principle the frame is still detectable. However, the entire SFD
    sequence, and almost two bytes of Preamble ahead of it, had to have been
    received uncorrupted.

    But 100 Mb/s and faster Ethernets encapsulate their data frames
    differently, so that the preamble bits are inside a bigger envelope.
    Using 4B/5B signaling allows Fast Ethernet to define special symbols to
    denote Start of Stream Delimeter and End of Stream Delimiter. The SSD
    sequence occurs before the Preamble. The MII won't even see the Preamble
    sequence or the Ethernet frame if a proper SSD wasn't decoded by the PCS
    layer.

    IEEE 802.3 paragraph 24.2.2.1.4 and Figure 24-5 explain this. Use of
    4B/5B to encode SSD, ESD, and the data bits themselves, makes it highly
    unlikely that a decipherable frame would ever reach the MII without the
    full 56-bit Preamble and 8-bit SFD.

    Bert
  4. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Albert Manfredi wrote:

    (snip)

    > Here's my understanding of IEEE 802.3:

    > In 10 Mb/s Ethernet, 802.3 paragraph 9.6.1 says that 15 preamble bits
    > must be received before search for SFD begins (this is DataRdy state).
    > So if the interface was idle at the beginning, then it receives at least
    > 15 properly alternating preamble bits, then a correct SFD appears, the
    > receiver assumes this is the start of a new frame. If this doesn't
    > happen, that is, either the at least 15 correct preamble bits did *not*
    > follow an idle period, or a correct SFD byte wasn't detected after these
    > preamble bits, then the receiver won't assume any frame exists.

    > So if the first 41 bits of the 56-bit preamble were corrupted, in
    > principle the frame is still detectable. However, the entire SFD
    > sequence, and almost two bytes of Preamble ahead of it, had to have been
    > received uncorrupted.

    Trying to remember which definition this is, is the SFD all eight
    bits, so that at least 24 bits must be correct? It is interesting
    to figure the probability of accidental recognition of a frame, such
    as connecting to a network while it is running. If 24 preamble/SFD
    bits had to agree, plus the 32 bit CRC, that would make 2**-56 the
    chance of an accidental frame being detected when connecting to
    an active network.

    -- glen


    In addition,
    the 32 bits of CRC at the end must also agree.
  5. Archived from groups: comp.dcom.lans.ethernet (More info?)

    "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:

    I had written:

    > > So if the first 41 bits of the 56-bit preamble were corrupted, in
    > > principle the frame is still detectable. However, the entire SFD
    > > sequence, and almost two bytes of Preamble ahead of it, had to have
    been
    > > received uncorrupted.
    >
    > Trying to remember which definition this is, is the SFD all eight
    > bits, so that at least 24 bits must be correct? It is interesting
    > to figure the probability of accidental recognition of a frame, such
    > as connecting to a network while it is running. If 24 preamble/SFD
    > bits had to agree, plus the 32 bit CRC, that would make 2**-56 the
    > chance of an accidental frame being detected when connecting to
    > an active network.

    If you need 15 preamble bits directly before the 8 SFD bits, that would
    add up to 23 bits total, rather than 24. But we're quibbling. I guess my
    point was that with the faster Ethernets I don't think such
    considerations are really meaningful anymore. Since the original post
    was about MII, that would include both 10 and 100 Mb/s Ethernets, and I
    just don't see the short preamble scenario being much of an issue with
    100 Mb/s.

    Bert
  6. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Albert Manfredi wrote:
    > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:

    > I had written:

    >>>So if the first 41 bits of the 56-bit preamble were corrupted, in
    >>>principle the frame is still detectable. However, the entire SFD
    >>>sequence, and almost two bytes of Preamble ahead of it,
    > had to have been received uncorrupted.

    >>Trying to remember which definition this is, is the SFD all eight
    >>bits, so that at least 24 bits must be correct? It is interesting
    >>to figure the probability of accidental recognition of a frame, such
    >>as connecting to a network while it is running. If 24 preamble/SFD
    >>bits had to agree, plus the 32 bit CRC, that would make 2**-56 the
    >>chance of an accidental frame being detected when connecting to
    >>an active network.

    > If you need 15 preamble bits directly before the 8 SFD bits, that would
    > add up to 23 bits total, rather than 24. But we're quibbling. I guess my
    > point was that with the faster Ethernets I don't think such
    > considerations are really meaningful anymore. Since the original post
    > was about MII, that would include both 10 and 100 Mb/s Ethernets, and I
    > just don't see the short preamble scenario being much of an issue with
    > 100 Mb/s.

    Extending the improbable even more, it might be that the noise
    of the connectors making contact could make something that looks
    like the SSD code on a 100baseTX connection.

    So it would seem that there is still a use for the preamble
    after all, to make sure that false frame detection really
    is improbably low.

    -- glen
  7. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <52053ea0.0407150447.50249409@posting.google.com>,
    mittal@einfochips.com (mittal patel) wrote:

    > >
    > > > Hi,
    > > >
    > > > I want to know exactly how the SFD detection algorithm works for MII MAC
    > > > receiver.
    > >
    > > SFD detection is completely specified in the IEEE 802.3 standard,
    > > available free from standards.ieee.org.
    >
    > Yes, it's given in the 802.3 standard. The PhysicalSignalDecap
    > function in the standard says: "receive one bit at a time from the
    > physical medium until a valid sfd is detected". But when working at
    > the MII interface, 4 bits are received by the MAC at a time. Therefore
    > 1)Should MAC check 4 bit pattern 101011 or 8 bit pattern 10101011.

    The SFD is an 8-bit field, therefore the MAC must check 8 bits to
    determine the presences of an SFD (2 nibbles across the MII).

    > 2)If the Preamble is corrupted, should the corrupted preamble ptterns
    > be ignored, except the one which is similer to sfd.

    In the original 10 Mb/s design, preamble was *expected* to be corrupted;
    that's part of the reason why a preamble was sent before any data. In
    this way, the "throwaway" preamble would experience the corruption
    rather than the important data. Preamble corruption came about from:
    decoder (PLL) startup phase/frequency offset, lowered S/N ratio (i.e.,
    error robustness) while the cabling system and transceiver electronics
    were coming to steady-state, external noise, etc.

    The standard specifies that a valid SFD signifies the start of the MAC
    frame. Preamble (corrupted or not) was ignored. That said, most *robust*
    10 Mb/s implementation looked for some amount of valid preamble before
    accepting a (presumed valid) SFD; my own designs looked for at least 16
    valid preamble bits before accepting an SFD.

    In 100 Mb/s systems, continuous signaling and the use of Start-of-Stream
    Delimiters (SSD) virtually guarantees that the entire preamble will be
    uncorrupted; however, an MII-based design must also allow for 10 Mb/s
    PHYs, so you can't depend on this behavior.

    Bottom line: I would recommend that you look for some number of valid
    preamble bits, plus an 8-bit SFD, to qualify a MAC frame.

    > 3) what if sfd is corrupted and data contains sfd pattern.

    If the "real" SFD is corrupted, then it will not trigger the start of
    the frame. If there is an SFD pattern within the data, it could trigger
    a false start. However, the likelihood that such a frame would be passed
    up to a client is vanishingly low. First, if you follow the advice from
    above, the frame would have to contain both 16 (or more) bits of
    preamble (101010...) immediately prior to the ersatz SFD. Second, the
    32-bit FCS would also have to match "by chance", which has (at best) a 1
    in 2^32 probability. Third, the MAC will then inspect the fields after
    the ersatz SFD; e.g., the MAC DA would somehow have to match the
    station's unicast (or some enabled multicast) address, the Type field
    would have to appear valid, etc. All of this is highly unlikely.

    In addition, the upper layer client will also be imposing some syntactic
    restrictions. For example, if somehow the fields following the ersatz
    SFD did pass the MAC address/Type/FCS constraints, *plus* it was aligned
    on octet boundaries, the payload would also have to "appear" like an IP
    datagram, or whatever Network or other client protocol was using the
    Ethernet. Possible, but not worth worrying about.

    Remember that this frame was already corrupted (due to the corruption of
    the SFD); the proper behavior is to detect the error and discard the
    frame, not to somehow recover from the corrupted SFD.

    > 4)If MAC don't find sfd within first 8 bytes (i.e max(preamble+sfd)),
    > should it stop frame collection after the 8 bytes considering sfd
    > error.
    >

    Remember that, in 10 Mb/s systems, you can't always depend on the
    integrity of the clock during decoder PLL synchronization. Noise might
    cause lots of extraneous zero-crossings in the early data, making it
    appear (to the MAC) that there were a lot more than 64 preamble bits, if
    it was using the receive clock as its reference. Just keep looking for
    the SFD, no matter how long it takes. You have nothing to lose.


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  8. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <I0wIu5.Mu6@news.boeing.com>,
    "Albert Manfredi" <albert.e.manfredi@nospam.com> wrote:

    > In 10 Mb/s Ethernet, 802.3 paragraph 9.6.1 says that 15 preamble bits
    > must be received before search for SFD begins (this is DataRdy state).
    > So if the interface was idle at the beginning, then it receives at least
    > 15 properly alternating preamble bits, then a correct SFD appears, the
    > receiver assumes this is the start of a new frame. If this doesn't
    > happen, that is, either the at least 15 correct preamble bits did *not*
    > follow an idle period, or a correct SFD byte wasn't detected after these
    > preamble bits, then the receiver won't assume any frame exists.
    >

    Clause 9 specifies only *repeater* operation; this is not a
    specification for a 10 Mb/s end station receiver.


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  9. Archived from groups: comp.dcom.lans.ethernet (More info?)

    "Rich Seifert" <usenet-@-richseifert-dot-com.invalid> wrote:

    > Clause 9 specifies only *repeater* operation; this is not a
    > specification for a 10 Mb/s end station receiver.

    True. However, in the early days, weren't all Ethernet end stations
    connected via a MAU of some sort? Since a MAU is either used with end
    stations or as one component of a repeater, it seems hard to rationalize
    any difference in how they are to decode frames.

    My intepretation of the standard would be that requirements of the 10
    Mb/s repeater and the MAU are intended to be the same with respect to
    transmitting and receiving frames to/from the coax medium. I realize
    there are no words that explicitly say this *with respect to the
    preamble*, but here is the series of quotes that leads me to this
    general conclusion:

    -------------------------------------------------
    7.2.3.2 Preamble

    The <preamble> delimiter begins a frame transmission and provides a
    signal for receiver synchronization. The signal shall be an alternating
    pattern of (CD1) and (CD0). This pattern shall be transmitted on the
    Data Out circuit by the DTE to the MAU for a minimum of 56 bit times at
    the beginning of each frame. The last bit of the preamble (that is, the
    final bit of preamble before the start of frame delimiter) shall be a
    CD0.

    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.

    8.1.1.1 Medium Attachment Unit

    The MAU has the following general characteristics:

    a) Enables coupling the PLS by way of the AUI to the explicit baseband
    coaxial transmission system defined in this clause of the standard.

    b) Supports message traffic at a data rate of 10 Mb/s (alternative data
    rates may be considered in future additions to the standard).

    c) Provides for driving up to 500 m of coaxial trunk cable without the
    use of a repeater.

    d) Permits the DTE to test the MAU and the medium itself.

    8.1.1.2 Repeater unit

    The repeater unit is used to extend the physical system topology, has
    the same general characteristics as defined in 8.1.1.1, and provides for
    coupling together two or more 500 m coaxial trunk cable segments.
    Multiple repeater units are permitted within a single system to provide
    a maximum trunk cable connection path of 2.5 km between any two MAUs.

    9. Repeater unit for 10 Mb/s baseband networks

    9.1 Overview

    [ ... ]

    A repeater set connects segments of network medium together, thus
    allowing larger topologies and a larger MAU base than are allowed by
    rules governing individual segments.

    [ ... ]

    If the repeater set uses MAUs connected via AUIs to a repeater unit,
    these MAUs shall not perform the signal_quality_error Test function. A
    manufacturer may, optionally, integrate one or all MAUs into a single
    package with the repeater unit (internal MAUs). In all cases, the MAU
    portion of the repeater set must be counted toward the maximum number of
    MAUs on each segment. A repeater set is not a station and does not count
    toward the overall limit of 1024 stations on a network.

    [ ... ]

    9.6.1 State diagram notation


    [... ]

    DataRdy


    Indicates the repeater has detected the SFD and is ready to send the
    received data. The search for SFD shall not begin before 15 bits have
    been received. Note, transmit and receive clock differences shall also
    be accommodated.

    ------------------------------------------------------------


    I would conclude that any MAU, whether associated with an end station or
    a repeater, was expected to work pretty much the same, when it comes to
    the coax medium interface?


    Bert
  10. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <I148vq.B6I@news.boeing.com>,
    "Albert Manfredi" <albert.e.manfredi@nospam.com> wrote:

    > "Rich Seifert" <usenet-@-richseifert-dot-com.invalid> wrote:
    >
    > > Clause 9 specifies only *repeater* operation; this is not a
    > > specification for a 10 Mb/s end station receiver.
    >
    > True. However, in the early days, weren't all Ethernet end stations
    > connected via a MAU of some sort? Since a MAU is either used with end
    > stations or as one component of a repeater, it seems hard to rationalize
    > any difference in how they are to decode frames.
    >

    Except that the MAU doesn't parse the frames; that is done by the MAC
    (in an end station) or the repeater state machine (in a repeater). The
    fact that the same MAU could be used with an end station or a repeater
    is irrelevant to the issue in question, since the SFD detection is not
    performed within the MAU.


    >
    > I would conclude that any MAU, whether associated with an end station or
    > a repeater, was expected to work pretty much the same, when it comes to
    > the coax medium interface?
    >

    That is true (except that "heartbeat" must be disabled on MAUs connected
    to 10 Mb/s repeaters.).


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  11. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Albert Manfredi <albert.e.manfredi@nospam.com> wrote:
    > "Rich Seifert" <usenet-@-richseifert-dot-com.invalid> wrote:
    >> Clause 9 specifies only *repeater* operation; this is
    >> not a specification for a 10 Mb/s end station receiver.
    >
    > True. However, in the early days, weren't all Ethernet
    > end stations connected via a MAU of some sort? Since a MAU
    > is either used with end stations or as one component of a
    > repeater, it seems hard to rationalize any difference in
    > how they are to decode frames.

    AFAIK a MAU doesn't have _any_ intelligence at all and
    doesn't decode frames. It is more of a hardware tranceiver
    designed to keep the transmission medium "clean".

    -- Robert
  12. Archived from groups: comp.dcom.lans.ethernet (More info?)

    "Robert Redelmeier" <redelm@ev1.net.invalid> wrote:

    > AFAIK a MAU doesn't have _any_ intelligence at all and
    > doesn't decode frames. It is more of a hardware tranceiver
    > designed to keep the transmission medium "clean".

    True, the MAU has no "intelligence," but it is the MAU that clobbers
    these preamble bits. So any specs regarding how many preamble bits
    should come before the SFD, it seems to me, are primarily there to
    account for the electrical properties of the MAU.

    And since these same MAUs are used for end stations and for repeaters,
    .....

    Clauses 8.2.1.1 and 8.2.1.2 describe the transmit and receive function
    requirements of MAUs. That's where the existence of dropped and
    distorted bits is attributed to the MAU.

    I suppose one can argue that repeaters should have more stringent
    requirements with respect to preamble bits than end stations, simply
    because a repeater will be followed by more preamble trashing MAUs,
    whereas the end station is the end of the line. But in the absence of an
    explicit rule for end stations, my instinct is to use the explicit rule
    applied to repeater preambles.

    Bert
  13. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Albert Manfredi <albert.e.manfredi@nospam.com> wrote:
    > True, the MAU has no "intelligence," but it is the MAU that
    > clobbers these preamble bits. So any specs regarding how
    > many preamble bits should come before the SFD, it seems
    > to me, are primarily there to account for the electrical
    > properties of the MAU.

    Well, calling them "preamble bits" seems a bit ambitious.
    They seem more like a sync-up signal.

    > I suppose one can argue that repeaters should have more
    > stringent requirements with respect to preamble bits than
    > end stations, simply because a repeater will be followed

    I certainly would strongly argue such! Repeaters are
    there to re-form dirty waves (restore S/N) to they can
    be pushed out other wire for longer distances. Preamble
    bits need to be preserved because the MAUs need them.

    > by more preamble trashing MAUs, whereas the end station
    > is the end of the line. But in the absence of an explicit
    > rule for end stations, my instinct is to use the explicit
    > rule applied to repeater preambles.

    Well, in coax technology where MAUs were mostly used,
    there really is no "end station". MAUs were designed to
    be unobtrusive vampire taps.

    -- Robert
  14. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Thank you very much for your ealborated reply on each of the queries.

    Rich Seifert <usenet-@-richseifert-dot-com.invalid> wrote in message news:<usenet--5687F1.08554919072004@news-central.dca.giganews.com>...
    > In article <52053ea0.0407150447.50249409@posting.google.com>,
    > mittal@einfochips.com (mittal patel) wrote:
    >
    > > >
    > > > > Hi,
    > > > >
    > > > > I want to know exactly how the SFD detection algorithm works for MII MAC
    > > > > receiver.
    > > >
    > > > SFD detection is completely specified in the IEEE 802.3 standard,
    > > > available free from standards.ieee.org.
    > >
    > > Yes, it's given in the 802.3 standard. The PhysicalSignalDecap
    > > function in the standard says: "receive one bit at a time from the
    > > physical medium until a valid sfd is detected". But when working at
    > > the MII interface, 4 bits are received by the MAC at a time. Therefore
    > > 1)Should MAC check 4 bit pattern 101011 or 8 bit pattern 10101011.
    >
    > The SFD is an 8-bit field, therefore the MAC must check 8 bits to
    > determine the presences of an SFD (2 nibbles across the MII).
    >
    > > 2)If the Preamble is corrupted, should the corrupted preamble ptterns
    > > be ignored, except the one which is similer to sfd.
    >
    > In the original 10 Mb/s design, preamble was *expected* to be corrupted;
    > that's part of the reason why a preamble was sent before any data. In
    > this way, the "throwaway" preamble would experience the corruption
    > rather than the important data. Preamble corruption came about from:
    > decoder (PLL) startup phase/frequency offset, lowered S/N ratio (i.e.,
    > error robustness) while the cabling system and transceiver electronics
    > were coming to steady-state, external noise, etc.
    >
    > The standard specifies that a valid SFD signifies the start of the MAC
    > frame. Preamble (corrupted or not) was ignored. That said, most *robust*
    > 10 Mb/s implementation looked for some amount of valid preamble before
    > accepting a (presumed valid) SFD; my own designs looked for at least 16
    > valid preamble bits before accepting an SFD.
    >
    > In 100 Mb/s systems, continuous signaling and the use of Start-of-Stream
    > Delimiters (SSD) virtually guarantees that the entire preamble will be
    > uncorrupted; however, an MII-based design must also allow for 10 Mb/s
    > PHYs, so you can't depend on this behavior.
    >
    > Bottom line: I would recommend that you look for some number of valid
    > preamble bits, plus an 8-bit SFD, to qualify a MAC frame.
    >
    > > 3) what if sfd is corrupted and data contains sfd pattern.
    >
    > If the "real" SFD is corrupted, then it will not trigger the start of
    > the frame. If there is an SFD pattern within the data, it could trigger
    > a false start. However, the likelihood that such a frame would be passed
    > up to a client is vanishingly low. First, if you follow the advice from
    > above, the frame would have to contain both 16 (or more) bits of
    > preamble (101010...) immediately prior to the ersatz SFD. Second, the
    > 32-bit FCS would also have to match "by chance", which has (at best) a 1
    > in 2^32 probability. Third, the MAC will then inspect the fields after
    > the ersatz SFD; e.g., the MAC DA would somehow have to match the
    > station's unicast (or some enabled multicast) address, the Type field
    > would have to appear valid, etc. All of this is highly unlikely.
    >
    > In addition, the upper layer client will also be imposing some syntactic
    > restrictions. For example, if somehow the fields following the ersatz
    > SFD did pass the MAC address/Type/FCS constraints, *plus* it was aligned
    > on octet boundaries, the payload would also have to "appear" like an IP
    > datagram, or whatever Network or other client protocol was using the
    > Ethernet. Possible, but not worth worrying about.
    >
    > Remember that this frame was already corrupted (due to the corruption of
    > the SFD); the proper behavior is to detect the error and discard the
    > frame, not to somehow recover from the corrupted SFD.
    >
    > > 4)If MAC don't find sfd within first 8 bytes (i.e max(preamble+sfd)),
    > > should it stop frame collection after the 8 bytes considering sfd
    > > error.
    > >
    >
    > Remember that, in 10 Mb/s systems, you can't always depend on the
    > integrity of the clock during decoder PLL synchronization. Noise might
    > cause lots of extraneous zero-crossings in the early data, making it
    > appear (to the MAC) that there were a lot more than 64 preamble bits, if
    > it was using the receive clock as its reference. Just keep looking for
    > the SFD, no matter how long it takes. You have nothing to lose.
Ask a new question

Read More

Detection Ethernet Card Macintosh Networking