|
Posted by Rich Seifert on March 16, 2008, 8:55 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> Rich Seifert wrote:
> > Michelot wrote:
>
> >>We can read in 802.3, §24.2.21.6: "The normal use of the /H/ indicator
> >>is for repeaters to propagate received errors".
> (snip)
>
> > Correct. The /H/ code is never needed in a switch. As you quoted, "The
> > normal use of the /H/ indicator is for *REPEATERS* to propagate received
> > errors." (Emphasis added.) Consider the situation of a 100 Mb/s repeater
> > that receives a frame that has been corrupted by noise such that the
> > repeater sees an invalid code-group. The repeater cannot (or at least,
> > should not) transmit the invalid code-group onto other ports, but the
> > repeater must transmit *something*
>
> What bad things happen with an invalid code group? Could it
> accidentally be changed (noise) to a valid one? The checksum would
> fail then.
Well, it's never a good idea to transmit something that is invalid.
Besides that, most of the 100BASE-X hardware was incapable of generating
invalid codes; there was just no way to tell the encoder to generate one
of the unused codes. The /H/ code is typically generated by an
out-of-band indicator (a specific input) to the encoder chip.
> (snip)
>
> > It would not be used by *any* switch, either in full-duplex or
> > half-duplex mode. A switch can simply discard a received frame that
> > contains an error; there is no need to propagate the signal to other
> > ports.
>
> There used to be stories about switches that would start sending
> before the whole frame was buffered.
> If all ports are the same
> speed and full duplex and no other data is already being sent
> it shouldn't be too hard to do. In that case, bad code groups
> would seem to again be a problem.
>
In the scenario you describe, the switch could simply truncate the frame
at the invalid code point. The receiver at the other end would discard
for a checksum error. The reason for /H/ codes is because repeaters have
to "keep repeating" to ensure collision detect; collision detect is not
needed for the full-duplex device you describe.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
| 
NewsGroups 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map