Re: [10GBT] Frame delineation in 10GBT
Shimon,
Good point. The "inherent" latency in the standard definition would be
increased by 45.5nS. However any reasonable implementation of 64b/65b
would involve 8 consecutive blocks in order to maintain byte alignment.
What's more, the LDPC implementation will have more than 10 times this
latency and I'm sure that a smart designer would fold the encapsulation
into the error coding so that the latency of the encapsulation will, in
effect, disappear.
I think that you raise an interesting point. Should we specify a minimum
latency through the PHY? A number of people have commented that there
will be tradeoffs in the LDPC implementation that could balance latency
with size/gate count/power. As I understand it, PHYs with different
implementations would be completely interoperable but the latency might
vary by a factor of 3 or more. (IIRC from ~800nS to 2uS for reasonable
implementations of the block codes that we are considering). Others who
know the codes should weigh in on this to say what they think would be a
reasonable requirement.
Hugh.
Shimon Muller wrote:
> My problem with the 64/65-byte encapsulation scheme is that it
> will add at least 50nsec of "inherent latency" for each end of
> the link, or at least 100nsec end-to-end. For most practical
> implementations it is likely to be quite a bit higher than that.
> This is the latency that we have been working hard to keep to
> the bare minimum (for all the reasons that I talked about back
> in January), including the decision to use LDPC codes.
> Personally, I would need a much better reason to increase the
> PHY latency than a "more elegant" way to do encapsulation.
>
> Shimon.
>