RE: Link Status encodings
Assuming that the MAC/RS does not stop packet transmission while it sends RF
indication, and that there is no /A/ column because the IPG is minimal:
Where will the POS be transmitted over the XAUI?
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Wednesday, November 29, 2000 11:21 PM
> To: HSSG
> Subject: Re: Link Status encodings
>
>
>
> Boaz,
>
> Please see my responses below.
>
> Boaz Shahar wrote:
> >
> > Some comments:
> >
> > 1) Since packet transmission process and Link Fault event
> are mutually
> > exclusive, it may happen that the RF Pulse ordered set (POS) must be
> > transmitted within a minimum size IPG. Such an IPG is
> composed of either /K/
> > or /A/ in the first column, and /R/ in the second. As it
> stands now, there
> > is no place for POS there. As a result, the number of
> packets or time until
> > the next POS is transmitted is not bounded.
>
> I never said that the packet transmission process and Link
> Fault "event"
> was mutually exclusive. They clearly are not. However, Packet
> transmission and POS (link fault message) transmission are mutually
> exclusive. IPG is not relevant to POS transmission. In link
> fault mode,
> ||P|| follows every ||A|| in the 10GBASE-X PCS.
>
> > 2)A possible solution may be to transmit POS instead of the
> first /R/. If it
> > has a neutral disparity it can be removed from the data
> stream as a result
> > of clock tolerance
>
> The 10GBASE-X PCS ENCODE process generates the code-groups associated
> with ||P|| with the proper running disparity on each lane. No
> insertion
> or removal of ||P|| is required by the draft. Since Packet
> transmission
> and ||P|| transmission are mutually exclusive, ||P|| follows
> every ||A||
> and there are statistically many more ||R||s than ||P||s in a
> Link Fault
> stream and any ||R|| may be inserted or removed, there is no reason to
> insert or remove ||P|| for clock rate compensation purposes.
>
> > 3)Another way is to choose either /A/ or /K/ for the first
> IPG column using
> > a Round Robin scheme, so /A/ will appear every second
> packet and so is the
> > POS.
>
> See my responses to (1) and (2).
>
> > 4)Yet another way is to say that the MAC/RS layers stop
> transmission of
> > packets (i.e. transmit /I/ columns) as soon as LF is
> detected. This solves
> > the above case, because the DTX XGXS transmits only IDLE
> pattern, so that
> > the distance between two adjacent /A/ (And there fore POS)
> is bounded.
> > However, I think that in this case you cannot ay that
> "packet transmission
> > process and Link Fault event are mutually exclusive".
>
> See my responses to (1) and (2).
>
> > Boaz
>
> Best Regards,
> Rich
>
> --
>
> > > -----Original Message-----
> > > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> > > Sent: Wednesday, November 29, 2000 9:10 AM
> > > To: HSSG
> > > Subject: Re: Link Status encodings
> > >
> > > Boaz,
> > >
> > > Idle mode is entered whenever any ||I|| (Idle column) is received.
> > > Packet (i.e. data) transmission is aborted at this time.
> The ||I|| may
> > > be the result of the beginning of fault message signaling, or the
> > > beginning of an Idle sequence following a packet. At the Node
> > > A DTE XGXS a link fault condition is recognized, and Fault mode is
> > > entered, after 3 RF Pulse ordered-sets are detected.
> Data/packet mode
> > > is mutually exclusive with Idle and Fault modes.
> > >
> > > Best Regards,
> > > Rich
> > >
> > > --
> > >
> > > Boaz Shahar wrote:
> > > >
> > > > A question:
> > > > When the DTE XGXS enters IDLE mode: Is it happens only
> > > after recognizing a
> > > > link fault condition? (3 times RF) or immediately after the
> > > first one? And
> > > > in this state: If the RS continue to transmit data, the DTE
> > > XGXS stays in
> > > > IDLE or transmits the data and only changes the idle
> > > pattern so that it
> > > > contains POS?
> > > > Boaz
>
> -------------------------------------------------------
> 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
>