|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
I've watched this thread with interest. And I have noted that the thread has not included any marketing response! It has also not included systems architects. Latency is a huge issue and it makes or breaks sales. It is also a marketing whip used in all debates between companies at various networking events. Just look at any marketing published data in trade rags or corp. lit.
From my perspective, I don't think anything above 200ns point to point is something to consider. Architects want to see less then 100ns. Point to point on a back plane communications path, you want to see less then 20ns. The back plane has to be the lowest it can be so the NP portion can have extra time as dictated by the memory available and the various algorithms employed to satisfy the total point to point latency. If you want to add latency at the 10baseT PHY, that's one thing as market will determine whether it is acceptable to do so. But adding it in at the back plane has architecture implications that may force us all back to an A/B analog fabric to meet total goals.
Code latency should have the same priority as code bandwidth.
Booth, Bradley wrote:
Greetings, To make a clarification on my request, I was not considering end-to-end latency as this is not the realm of 802.3. I was considering point-to-point latency, not for PAUSE although a latency number will be required for those that do implement flow control. The question comes to my mind, can we afford to (or better yet, can we afford not to) make trade-offs against latency for better performance. What are the pros and cons of these trade-offs? Do we need to consider latency against the coding proposals? BTW, I think it is great to see so much discussion around this. Maybe we should discuss line codes, etc. while we're at it? Cheers, Brad