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.
Hi,
I want to know exactly how the SFD detection algorithm works for MII MAC receiver.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
G
Guest
Guest
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
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
G
Guest
Guest
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
>
> > 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
G
Guest
Guest
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
"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
G
Guest
Guest
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.
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.
G
Guest
Guest
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
"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
G
Guest
Guest
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
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
G
Guest
Guest
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
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
G
Guest
Guest
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
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
G
Guest
Guest
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
"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
G
Guest
Guest
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
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
G
Guest
Guest
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
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
G
Guest
Guest
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
"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
G
Guest
Guest
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
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
G
Guest
Guest
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.
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.
TRENDING THREADS
-
Question can using a usb 3.0 to usb 2.0 adapter slow down the speed?- Started by MoriSori
- Replies: 2
-
RTX 4060 Ti vs RX 7700 XT faceoff: Which midrange graphics card is superior?- Started by Admin
- Replies: 26
-
Question HELP !!!!! My Desktop PC randomly sends monitors to standby???
- Started by EpicsGamer
- Replies: 7
-
News Ryzen 9 7950X3D surfaces with 192MB L3 cache — 3D V-Cache ES CPU has 64MB more than retail CPU
- Started by Admin
- Replies: 10
-
News Nintendo obliterates 8,535 Yuzu repos — Nintendo's most effective DMCA takedown campaign in years
- Started by Admin
- Replies: 39
Latest posts
-
Question HELP !!!!! My Desktop PC randomly sends monitors to standby???
- Latest: ohio_buckeye
-
-
Tom's Hardware is part of Future plc, an international media group and leading digital publisher. Visit our corporate site.
© Future Publishing Limited Quay House, The Ambury, Bath BA1 1UA. All rights reserved. England and Wales company registration number 2008885.
Facebook
Twitter
Instagram