Re: Question about Link Fault Signalling
****************** Virus Warning Message (on gemini2.ieee.org)
Found virus TROJ_NAVIDAD.E in file Emanuel.exe
The file is deleted.
If you have questions, contact virus-admin@xxxxxxxx
*********************************************************
A picture is worth a thousand words ...
Attached is a pdf of the state diagram for RS link status management.
Regards,
Birdy
-----------------------------------------------------
From: "David Gross" <dgross@xxxxxxxxxxxxxxxxxx>
Ben, Bob,
I also like the idea of not requiring some # of IDLEs to exit a fault
condition. If the fault no longer occurs that should cause the exit.
I do have a bit of a simple question, but I'd like to ask it just for
clarity:
When we say that "the reception of four status messages of the same type
shall indicate that the corresponding fault condition has occurred" I
interpret this to be within a time period of 4 clocks - that is 8
recieved groups. This seems to make sense if the recieved message is
alternated with IDLE characters (if IDLEs are deleted for timing, it
doesn't matter since we'll get 4 fault messages sooner). Since there was
no wording describing how long we have to detect the four fault messages
I thought I'd mention it just to be certain. Please correct me if my
assumption is wrong. Thanks.
Dave
Ben Brown wrote:
>
> Bob,
>
> I'll go one step further, in line with a recent note from Rich.
> The presence or absence of LF or RF ordered sets should decide
> what state the RS is in. Requiring some number of IDLEs to
> exit a state is undesirable (in my opinion). The case where
> a MAC is sending data when an RS leaves the LF state results
> in the link partner seeing RF followed directly by packets.
> Though this first packet will likely be trashed (and I have
> no problem with that), it should not require 8 words of IDLEs
> to exit the RF state, resulting in the loss of perhaps many
> packets if they all have minimum IPGs.
>
> Ben
>
****************** Virus Warning Message (on gemini2.ieee.org)
Emanuel.exe is removed from here because it contains a virus.
*********************************************************