RE: Link Status thoughts
Rich,
I agree with all the points made here. One thing I would like to see removed
from this proposal is the requirement to shut down the transmitter if a
receive link fault has been detected. As we are moving into the multimedia
arena, it is useful to have the transmitter to continue while the receive
path is being investigated. There are many multicast, broadcast applications
that can benefit from this.
What I am asking is the following options:
Once a link fault has been detected:
1) Shut down transmission and transmit link fault message
2) Continue with transmission and also transmit link fault
message
Regards,
Sharam
> ----------
> From: Rich Taborek[SMTP:rtaborek@xxxxxxxxxxxxx]
> Reply To: rtaborek@xxxxxxxxxxxxx
> Sent: Friday, November 03, 2000 9:37 PM
> To: HSSG
> Subject: Re: Link Status thoughts
>
>
> Shimon,
>
> It sounds like we're all getting very close to a compromise solution.
>
> I agree with your point of not performing Link Initialization or Link
> Status Reporting during normal data transfer. This point is almost
> implied in the fact that Link Initialization only occurs upon power-on,
> reset or link error. Similarly, most Link Status conditions will cause
> Link Status to be reset and MAC packet transmission to cease until the
> condition is cleared.
>
> It seems like we're converging on the following:
>
> 1) Local Fault and Remote Fault conditions;
> 2) Local Fault and Remote Fault messages;
> 3) Fault message Signaling by Signal or Sequence or something in between
> which is EMI-friendly;
> 4) No singaling during data transfer/packet;
> 5) No need for Break Link as part of power-on reset or link
> initialization;
> 6) Weak requirement for a management initiated Break Link, which could
> fire off a Remote Fault message.
>
> Did I miss anything?
>
> Best Regards,
> Rich
>
> --
>
> Shimon Muller wrote:
> >
> > I have been trying to follow this discussion very closely, and at this
> point
> > I have to admit that I am getting pretty confused. Pat is right, when
> the
> > e-mails get this long and this frequent, it is time for a face-to-face
> meeting.
> > I will be arriving around 7:00pm on Sunday as well, and am pretty much
> free
> > until Tuesday morning, except for Geoff's show on Monday. If someone
> wants to
> > set a time and place for a get-together, I would be happy to
> participate.
> >
> > Between now and Monday I would like you to think about the following:
> > I find myself agreeing with many points made by both Pat and Rich.
> Personally,
> > I am open to any suggestion that will make my proposal simpler and more
> robust.
> > Even to the extent that the final solution doesn't look close to what I
> have
> > proposed. However, the one thing that I will have trouble accepting is
> allowing
> > this signalling, whatever it is, during normal data transfer. I truly
> believe
> > that this would be a recipe for disaster.
> > If we can reach an agreement on this point, the rest is details, and I
> would
> > be happy to work on them.
> >
> > Shimon.
>
> -------------------------------------------------------
> 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
>