Re: Local Fault/Remote Fault
Pat,
I don't see any objection in your note about my claim that "a RF
condition should cause Link Status to be set to Fail in
the RF transmitting and receiving devices." So I'll assume that you
agree with it.
As to your point about receiving lock even with minimum IPG, I agree.
However, the 10GBASE-X PCS Synchronization state machine hysteresis will
typically prevent a link which has lost sync (a serious link error) from
regaining sync unless the original fault condition is remedied. This is
exactly why Link Status should be set to Fail for the link. This
protocol allows Station Management to monitor the condition of the link
in a more "sync friendly" environment. If the link still does not come
up when transmitting only Idles or Fault messages, the link should be
deactivated until it is repaired.
Best regards,
Rich
--
pat_thaler@xxxxxxxxxxx wrote:
>
> Rich,
>
> If a device is receiving RF, it doesn't even get a unidirectional link by
> transmitting. The other side is telling it it can't hear the transmission,
> so if it transmits it is going into half a unidirectional link - a
> transmitter without a receiver. A unidirectional link would only be achieved
> by enabling packet transmission while receiving LF.
>
> All our links will achieve lock even with minimum IPGs. In the case of
> 10GBASE-X, lock will take longer under that condition - worst case, one gets
> an A or a K each minimum IPG but it is statistical which one gets so it
> probably takes between 10 and 20 frames to have a high probability of having
> gotten enough to get lock but it will occur. It is better to switch to idle
> so lock reoccurs quickly when it is able, but we would still lock if we
> didn't.
>
> Regards, Pat
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Tuesday, January 02, 2001 3:39 PM
> To: HSSG
> Subject: Re: Local Fault/Remote Fault
>
> Eric,
>
> This is worth a comment, because it is what we voted in as a baseline
> proposal in Tampa in taborek_2_1100.pdf (see page 5 and others). I don't
> believe that a unidirectional Ethernet link is of any value to the user.
> Therefore, a RF condition should cause Link Status to be set to Fail in
> the RF transmitting and receiving devices. In addition, how else is the
> failing link direction going to get a chance to heal if it broke while
> it was receiving, at best, only Idles, and at worst, Idles with minimum
> IPGs.
>
> Happy Holidays,
> Rich
>
> --
>
> Eric Lynskey wrote:
> >
> > Rich,
> >
> > This is something I've been trying to figure out for a while. Perhaps you
> > can shed some light on this.
> >
> > > 3. The RS layer is where the Local Fault Pulse Ordered Set is
> > > processed. The RS layer is the only place that a Remote
> > > Fault Pulse Ordered Set can be generated. If an RS receives
> > > a Local Fault Pulse Ordered Set it must stop sending packets
> > > and begin sending alternating columns of Idles and Remote
> > > Fault Pulse Ordered Sets. If an RS receives a Remote Fault
> > > Pulse Ordered Set, it must stop sending packets and send
> > > only Idles.
> >
> > I cannot find any indication that if an RS receives a Remote Fault Pulse
> > Ordered Set, that it must stop sending packets and send Idles. As far as
> I
> > can tell, all Clause 46 says about reception of Remote Fault messages is
> > that this "indicates that the link partner DTE has detected a fault (and
> > consequently will not transmit frames." I know the end paranthesis is
> > missing, but I take that to simply mean that the link partner will not
> > transmit frames, but it says nothing about the local device inhibiting
> > transmission of MAC frames. Later on, it describes what happens when the
> > local device receives local fault messages, but nothing about remote fault
> > messages. What exactly was your intention with this? Should the local
> > device stop transmitting frames when it receives Remote Fault status
> > messages? It seems as if this is so, and I'll submit a comment about it
> if
> > that is correct.
> >
> > Eric Lynskey
> > UNH InterOperability Lab
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com