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

Re: HARI Latency




Rich,

The latency figure that you gave is that of data through fiber.  What is the latency
through the gates at each end of the Hari encode and decode/alignment gates?  What
would be the latency if the PCS encoding were not 8B10B?

Thank you,
Roy Bynum

Rich Taborek wrote:

> Dan,
>
> Sorry about not responding previously to your point. I've included your original
> question below also.
>
> Relative to the latency of the media, amounting to approximately 5 us per km,
> the added latency of Word-Striping over Byte/Column-Striping can be considered
> to be negligible when applied to a PMD interface.
>
> I don't agree about its simplicity relative to that of Byte/Column-Striping.
>
> I don't understand your comment about Word-Striping preserving the 8B10B coding
> used for GigE since the Word-Striping proposal for 10 GbE convolutes the
> translation of information form the MAC through the PCS, whereas
> Byte/Column-Striping preserves the coding quite well. I've previously
> illustrated this as follows:
>
> D<0:7>   wwww...IISddddd/dddddIIISddd/ddddIIISdddd...   Legend: I=Idle
> D<8:15>  rrrr...IIdddddd/ddddTIIIdddd/ddddIIIddddd...           S=SOP
> D<16:23> dddd...IIdddddd/ddddIIIIdddd/ddddIIIddddd...           T=EOP
> D<24:31> 3210...IIdddddd/ddddIIIIdddd/dddTIIIddddd...           d=data
>
> Figure 1 - Parallel 10 GMII stream
>
> Proposed Byte striping for 10 GbE is shown in figure 2 using Howard
> Frazier, Cisco, mapping per
> http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/frazier_1_1199.pdf
> page 15
>
> Lane 0   wwww...KRSddddd/dddddKRKSddd/ddddKRKSdddd...   Legend: K=Comma/Idle
> Lane 1   rrrr...KRdddddd/ddddTKRKdddd/ddddKRKddddd...           R=Idle
> Lane 2   dddd...KRdddddd/ddddRKRKdddd/ddddKRKddddd...           S=SOP
> Lane 3   3210...KRdddddd/ddddRKRKdddd/dddTKRKddddd...   d=data  T=EOP
>
> Figure 2 - Byte/Column Striping proposal for 10 GbE
>
> Proposed Word striping for 10 GbE is shown in figure 3 using Mark
> Ritter, IBM, mapping per
> http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/ritter_1_1199.pdf
> pages 15 and 16
>
> Lane 0   wrd0...Kidldddd/ddddKRTdKddS/ddddKidlKddd...   Legend: K=Comma
> Kidl=Idle
> Lane 1   wrd1...Kidldddd/ddddKidlKddd/ddddKidldddd...           R=Idle
> Lane 2   wrd2...KddSdddd/ddddKidldddd/ddddKidldddd...           S=SOP
> Lane 3   wrd3...Kddddddd/ddddKidldddd/TdddKddSdddd...   d=data  T=EOP
>
> Figure 3 - Word-Striping proposal for 10 GbE
>
> The Byte/Column-Striping proposal code-group stream is essentially identical to
> the Parallel 10 GMII stream, whereas the Word-Striping proposal code-group
> stream changes dimensions from vertical to horizontal in 4-byte increments. Also
> note that for Word-Striping the Ethernet Start-of-Packet does not occur in lane
> 0 and the relative complexity of determining the last byte of a packet.
>
> In summary, striping, although worse, is not the paramount reason to select
> Byte/Column-Striping over Word-Striping. However, I've identified many others in
> my striping evaluation criteria. In addition, other industry efforts utilizing
> Hari are significantly affected by this latency penalty. The primary purpose of
> Hari was to determine whether Hari can be specified in a protocol independent
> manner. The opinion of that group is that it can be so specified. Hari can also
> be PMD independent. As an architect, I would rather specify Hari in a protocol
> and independent manner for the sake of simplicity, interoperability and
> economics.
>
> If InfiniBand has chosen Byte/Column-Striping for latency reasons, among others,
> and Byte/Column-Striping better meets 10 GbE requirements including simple
> mapping... and Byte/Column-Striping can be simply mapped for 10 Gigabit Fibre
> Channel, then I see no advantage to Word-Striping and propose
> Byte/Column-Striping for Hari for all protocols and PMDs.
>
> Best Regards,
> Rich
>
> --
>
> "DOVE,DANIEL J (HP-Roseville,ex1)" wrote:
> >
> > Hi Rich,
> >
> > Would you respond to my earlier point about HARI byte vs word striping
> > and the negligible latency impact when applied to a PMD interface?
> >
> > I believe that word striping offers simplicity and preserves the 8B10B
> > coding used for GigE at the expense of additional latency, but I also
> > believe that this latency has virtually ZERO impact when applied to the
> > PMD implementations which are going to swamp it.
> >
> > On the other hand, I believe that word striping latency would seriously
> > impact backplane implementations, however, this is not the stated objective
> > for HARI, is it? If not, why should we not go to word striping?
> >
> > Dan Dove
>
> "DOVE,DANIEL J (HP-Roseville,ex1)" wrote:
> >
> > I agree with Mr. Widmer.
> >
> > The only area that I missed in his discussion involves the additional
> > latency of word-striping versus byte-striping.
> >
> > I can see where in a backplane implementation, latency is a concern.
> >
> > However, in the context of a MAC/PHY interface, the media latency will
> > dominate so heavily in the equation, a word-striped interface's latency
> > would be of no concern. Given that fact, for a MAC/PHY interface, all of
> > the benefits he points out should prevail.
> >
> > Best Regards,
> >
> > Dan Dove
> >
> > ___________     _________________________________________________________
> > _________    _/    ___________  Daniel Dove         Principal Engineer __
> > _______     _/        ________  dan_dove@xxxxxx     LAN PHY Technology __
> > _____      _/           ______  Hewlett-Packard Company                __
> > ____      _/_/_/ _/_/_/  _____  Workgroup Networks Division            __
> > ____     _/  _/ _/  _/   _____  8000 Foothills Blvd. MS 5555           __
> > _____   _/  _/ _/_/_/   ______  Roseville, CA 95747-5555               __
> > ______        _/      ________  Phone: 916 785 4187                    __
> > _______      _/      _________  Fax  : 916 785 1815                    __
> > __________  _/ __________________________________________________________
>
> -------------------------------------------------------------
> Richard Taborek Sr.         Tel: 408-330-0488 or 408-370-9233
> Chief Technology Officer                   Cell: 408-832-3957
> nSerial Corporation             Email: rtaborek@xxxxxxxxxxxxx
> 2500-5 Augustine Dr.           Alt email: rtaborek@xxxxxxxxxx
> Santa Clara, CA 95054