Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
>