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