Re: 8B/10B Code and Error Correction
- To: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
- Subject: Re: 8B/10B Code and Error Correction
- From: widmer@xxxxxxxxxx
- Date: Sun, 30 May 1999 17:20:05 -0400
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
---------------------- Forwarded by Albert X Widmer/Watson/IBM on 05/30/99 05:22
PM ---------------------------
Albert X Widmer
05/28/99 04:05 PM
To: Jaime Kardontchik <kardontchik.jaime@xxxxxxxxxxx>
cc: Mark Ritter/Watson/IBM@IBMUS, John Ewen/Watson/IBM@IBMUS, John
Crow/Watson/IBM@IBMUS
From: Albert X Widmer/Watson/IBM@IBMUS
Subject: Re: 8B/10B Code and Error Correction (Document link not converted)
I appreciate your concern about latency and buffer size. The implementation
example described in the patent targets long distance Fibre Channel links.
Since the Fibre Channel architecture is frozen, a maximum of transparency, i.e.
no visibility above the physical layer is a requirement, and it has to be
totally compatible with the existing architecture.
The reason to draw attention to an error correction option at this time is that
minor well planned
accommodations in the link and framing architecture of the 10Gb Ethernet
standard can significantly reduce the complexity of the error correction
implementation and increase its effectiveness. Error correction could be offered
as an option, perhaps only for the longer links. There are possible
implementations which do not delay error free data and do not require a
dedicated buffer. If there is interest, a proposal fitted to the 10Gb Ethernet
situation could be developed. I would be interested in participating in such a
working group.
If a dedicated buffer is even needed, its size is governed by the sacrifice in
throughput and the added delay we are willing to accept for purposes of error
correction. A limited buffer size does not constrain the data frames to the same
size. The two block sizes can remain totally unrelated. The overhead fraction is
(4 bytes)/(buffer size in bytes), so for a buffer size of 256 bytes, the
overhead amounts to 1.56% and the added delay is equivalent to 41 m of fiber
(5ns/m) for a link operating at 12.5Gbd.
Your estimate for the silicon area required for buffer implementation appears
too high by a significant factor. IBM 0.15 micron ASIC CMOS technology requires
37.632 micron_square per latch. So at 85% utilization, 22587 latches can be
fitted into one mm_square. A single latch occupies an area equivalent to 1.7
NAND3 gates. The point is that even the larger buffer sizes of interest require
a relatively insignificant silicon area in current CMOS technologies.
The latency at the system level should be our primary concern, where the latency
of a round-trip retransmission exceeds any other latency in the system. One
wants to minimize retransmission requests, and this is what error correction
does.
As you can see, there is plenty of flexibility to address your concerns from
various angles.