RE: Gearbox reality check

["Tim Armstrong" <tim@xxxxxxxxxxxxxxxxxx>]

Title: RE: Gearbox reality check

Rich,

Thanks for your clarification. It made me realize I needed to provide more
clarity myself.

My budget was really for the buffering requirements in the WIS functional
block as shown in slide 3 of:

http://grouper.ieee.org/groups/802/3/ae/public/may00/bottorff_1_0500.pdf

The rate adaptation between 10.000 Gb/s XGMII data rate and the ~ 9.29
Gb/s WAN PHY rate that you refer to will require buffering in either the PCS
or in the MAC layer. See slides 38, 40-41 of the presentation referenced
above. If it is in the MAC layer, it will likely be common to LAN and WAN
PHYs. Similarly, if it ends up in the PCS and vendors choose to implement
a common PCS for LAN and WAN, then it will be common to both.

For standard Ethernet maximum-length frames, the MAC/PCS rate
adaptation will require < 110 octets. (If you were to add this to the WIS
buffer, the total would be ~ 1k octets per direction).

If vendors choose to support LTL frames then, as you point out, ~ 630 octets
will be required for the MAC/PCS rate adaptation.  

Some more detail on my WIS buffer budget:

The WIS payload capacity is 9.584640 Gb/s. The 576 + 64 octet portion of
my budget absorbs the difference between that payload rate and the nominal
9.95328 Gb/s WAN PHY line rate. The 192 octets for pointer adjustments
handles any offset from nominal rates when crossing any WIS/PCS clock
boundaries. The sum, after including a few octets for jitter tolerance and a
reasonable read/write pointer separation, will come in below 1k octets per
direction.

I hope we can agree that the cost of this buffering (and the other WAN PHY
functions) is trivial and represents a very small price to pay in order for
Ethernet to gain easy access to the existing SONET/SDH-based WAN
infrastructure.

Tim Armstrong

-----Original Message-----
From:   Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxx]
Sent:   Tuesday, June 27, 2000 10:59 PM
To:     HSSG
Subject:        Re: Gearbox reality check




Tim,

I didn't want to use the "J" word in my previous note on this issue, so instead
I'll refer to "larger-than-life" frames. Note that based on the size of these
LTL frames, there is an additional buffering requirement for the WAN PHY of >7%
of the frame size due to the speed difference between the 10 Gbps PHY data rate
and the 9.29 WAN PHY data rate. For a 9 KB LTL frame, the buffering requirement
would be an additional 630 bytes per data direction over and above the numbers
you stated in (1) below.

Note that additional buffering specific to LTL frames is not applicable to a LAN
PHY regardless of frame size.

I believe that once all the buffering requirements are listed and applicable
macros are identified that the actual WAN PHY buffering requirements to provide
the equivalent frame transport as the LAN PHY will be in the 5 KB to 10 KB
range.

I'm sure I'll get blasted for this blasphemous response, but what the heck :-)

Best Regards,
Rich
    
--

> Tim Armstrong wrote:
>
> The WAN PHY buffering requirements will be less than 1K octets per direction.
>
> 1) The requirements for accommodating the overhead gaps are determined by the
>     worst case consisting of: Path overhead and fixed stuff immediately
> following
>     a positive pointer adjustment in row 4 of the SONET frame. The buffer
>     requirements are then:
>
> 576 octets for transport overhead
> 192 octets for positive pointer adjustments
>  64 octets for Path overhead and fixed stuff
> plus a few octets for jitter and clock domain hand-off.
>
> 2) There is minimal buffering required for the WAN PHY framing and scrambling
>     functions. Typically, pipeline stage re-timing is sufficient.
>
> Tim Armstrong
>
>      -----Original Message-----
>      From:   Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxx]
>      Sent:   Wednesday, June 21, 2000 5:45 PM
>      To:     HSSG
>      Subject:        Re: Gearbox reality check
>
>      Roy,
>
>      Sure. The buffering requirements for the Serial LAN PHY, with 64B/66B as
>      it's PCS are very small, implementation specific, and at worst perhaps
>      one or two hundred bytes or so to perform all of the following functions:
>
>      1) Implementation specific clock tolerance compensation only for the case
>         where multiple clock domains are implemented;
>      2) Implementation specific Gearbox input and output buffering;
>      3) Link synchronization stream buffering;
>      4) General implementation specific buffering requirements.
>
>      For the WAN PHY, buffering requirements are one to two orders of
>      magnitude greater (~10K bytes?), and include all the above plus buffering
>      to perform all of the following functions:
>
>      1) Rx and Tx buffering to account for SONET overhead bytes present in
>         each row;
>      2) General SONET framing and scrambling implementation specific buffering
>         requirements.
>
>      64K of buffering sounds pretty wild. A memory manager... for what? One is
>      certainly not required for the LAN PHY. It would be a stretch to call the
>      ~10K buffer management circuitry of a WAN PHY a "memory manager".
>
>      I'm sure that what you call a "gearbox" for PoS bears no resemblance
>      whatsoever to the 66:16 gearbox for 10 GbE.
>
>      Best Regards,
>      Rich
>
>      --
>
>      Roy Bynum wrote:
>      >
>      > Ben,
>      >
>      > Finally, someone is coming close to defining the "gear box", the piece
>      of "magic" that everyone is referring to in order to make the
>
>      > WIS work.  Now, can you codify the amount of buffering required, and
>      the flow differential alignments required to provide for the
>
>      > total possible adjustment needed between the SONET framer and the
>      64B/66B PCS?  For example, would 64k of multi-port memory as a
>
>      > FIFO buffer, with asynchronous clocked registers on either side to
>      provide for the bit and a robust memory manager provide the
>
>      > required functionality?  Is 64K enough.  Is it more than what is
>      needed? Are FIFO registers required?  Is a memory manager needed,
>
>      > and if so, what kind?
>      >
>      > The reason that I ask this question is that in my years of experience
>      with PoS, which uses a "gear box", it has proven to have a
>
>      > massive lack reliability compared to 802.3 Ethernet.  For example, the
>      GbE transport error rate is about 3e-8 to 2e-10 errored
>
>      > frames, depending on
>      > the frame size.  Compare this to the goal of only 3e10-2 dropped and
>      errored packets over IP/PoS, and other services at 2e10-3 frame
>
>      > error rate.
>      > ATM with a HEC frame structure has a much better reliability, 1e-8 to
>      1e-10 depending on the service.  Is P802.3ae willing to take a
>
>      > chance with a technology architecture that is associated with
>      un-reliable data communications or would it rather use something that
>
>      > is associated with reliable data communications?  As a customer, it is
>      very important for me to know.
>      >
>      > Thank you,
>      > Roy Bynum
                                
-------------------------------------------------------
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