Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [HSSG] Yet another topic for consideration - bit parallel

Most of the latency occurs in the portion of the serializer / deserializer inside the MAC (in an actual implementation...from say 64:4 or 64:10 bits) ... and not the last stages (from say 4:1 or 10:1 bits)

Considering the BW limitations of a backplane, a HSSG serial backplane approach is going to need FEC (considering that 10G KR needs FEC to go 39")... so in actuality, in a backplane application, the serial solution will have worse latency since any such FEC will have more latency than the deskew budget.  This all presumes that there will be a serial HSSG backplane solution (which seems unlikely).

-----Original Message-----
From: Kevern, James D [mailto:james.kevern@xxxxxxxxxxxxxxxxxxx] 
Sent: Wednesday, August 02, 2006 4:10 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Yet another topic for consideration - bit parallel

Certainly the deskewing would introduce latency, but perhaps another way of looking at that is that the media delay will be equal to whichever lane is slowest.  So in modelling overall performance one might use an extreme value distribution rather than gaussian to model the physical layer propagation delay (Tx, medium, Rx).

In my simplified view there's a delay associated with the parallel to serial conversion, the wider the slow speed path, the greater the multiplexing latency.  But perhaps all these are so small compared to the physical layer propagation delay that they will only matter when the distance is short, such as backplane implementations.
Best regards,

-----Original Message-----
From: Menachem Abraham [mailto:mabraham@xxxxxxxxxxxxxxxxxxxx] 
Sent: Tuesday, August 01, 2006 8:00 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Yet another topic for consideration - bit parallel


Regarding your question on latency tradeoffs in serial versus multi-lane approaches:

I think this is an important topic to discuss. I have the impression that this is closely related to the question of how much delay differential we allow between lanes. 

Intuitively I would say that a pure serial implementation should have less latency than a multi-lane approach.

In a multi-lane implementation, for example (and please all correct me if I am wrong) at 100 Gb/s, if we allow a 10 nanosecond delay differential between lanes, we will have to introduce latency at least on the order of 10 nanoseconds in the deskewing function in the receiver. While that does not seem like much, it is equivalent to two minimum size packets at 100 Gb/s. On the other hand, to put this latency in perspective, 10 nanoseconds is about 2 meters of cable.

Also, I suspect that some of the packet processing on the system side of the MAC may have some parallel elements which implies added latency as well.

Having said all of this, my sense is that all of these latency contributions to the latency in a server's network adaptor hardware or a switch are not at the level that will have an impact on the intended applications performance (assuming we do not allow too much differential delay between lanes).

Sent from my Blackberry 

-----Original Message-----
From: "Kevern, James D" <james.kevern@xxxxxxxxxxxxxxxxxxx>
Date:         Wed, 2 Aug 2006 10:04:41 
Subject: [HSSG] Yet another topic for consideration - bit parallel

Along with a previous suggestion that we become more educated on the problems associated with n x 10G LAG implementations, I, for one, would like to better understand the concerns regarding what I'll call bit parallel vs serial implementations.  There was an earlier post indicating MAC implementations might be in the order of 64 wide, maybe even 128.  So at the one extreme, one could envision a parallel connection 64 wide, at the other extreme is time division multiplexing this down to a single serial stream.  Note, that for this discusion, it does not matter whether the parallel paths are accomplished by individual cables, individual fibers in one cable, different wavelengths on a single fiber, or even individual traces on a backplane.  As has been mentioned, there are various possibilities in between the extremes, such as 10x 10 Gig, N x M, etc.
There are, of course, the obvious cost and reliability issues of number of sources, detectors, fibers, connectors, space constraints, etc.  But what about performance issues such as latency and throughput.  How would bit parallel differ from LAG?  Are there other issues as well?
This is a specific case of what could be considered a broader topic related to how we organize our work.  In addition to, as Menachem suggested, prioritizing application spaces, perhaps building a knowledge foundation, whether through postings here, tutorial presentations, links to web sites, etc. could be an early part of the effort.

Jim Kevern
Principal Engineer - Applications
Fiber Optics Business Unit
tyco / Electronics 
( phone: 717-986-5701
2 fax: 717-986-5449
: e-mail : james.kevern@xxxxxxxxxxxxxxxxxxx 
. Mailing Address: 
U.S. Mail (except Express Mail, which REQUIRES a street address): 
MS 258-002
PO Box 3608
Harrisburg, PA 17105-3608 
Shipping Address: 
UPS, FedEX, U.S. Express Mail, NOT U.S. Priority Mail: 
MS 258-002
2900 Fulling Mill Road
Middletown, PA 17057