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

RE: [10GBASE-T] Feedback from ISO/IEC WG 3 meeting

Title:
Maybe somebody can explain to me a a little more detail (to make sure I understand!):
 
1) It was agreed that the "self-induced" noise sources (NEXT, return loss ELFEXT) and the expected signal losses would match those specified for ISO/IEC 11801-2002, and the initial performance characteristics over 250 MHz would be extrapolated using the same formulas.
 
2) There have been some suggestions on what Alien NEXT affects could be (from some cabling suppliers).
 
Is it possible that the iterative process could be:
1) Determine the net noise contribution from self-induced sources.
2) Depending on a possible coding scheme, determine the maximally allowed Alien Crosstalk noise contributions (and throw this back to the cabling folks)? Or are there too many schemes to select from?
 
I believe that the modeling concepts that apply to within a cable, also apply to the alien crosstalk for a channel. These are identified in Annex G of ISO/IEC 11801-2002. While it is not too difficult to establish the absolute worst case one may find (which will be rather unrealistic, and likely not acceptable), it is much more difficult to generalize for practical installations the amount of margin that is achieved by "randomness" of the routing of cabling.
 
I hope to attend the next meeting in Orlando, so a long answer can wait.
 
Henriecus ("Henri" or "Riekus") Koeman

E-mail: henriecus.koeman@flukenetworks.com

-----Original Message-----
From: Thomas Dineen [mailto:tdineen@ix.netcom.com]
Sent: Wednesday, March 03, 2004 4:24 PM
To: pat_thaler@agilent.com
Cc: bradley.booth@intel.com; stds-802-3-10gbt@ieee.org
Subject: Re: [10GBASE-T] Feedback from ISO/IEC WG 3 meeting

Pat:

 I agree:

"Choose a coding scheme with a Nyquist frequency of x
Get told the channel parameters to x (or x * (1 + y) to allow for excess bandwidth)
Verify coding scheme operation with that channel
If results not satisfactory, choose new coding scheme, adjust x and y, and repeat."

   Well said:

   My concern is that if we pin down parameters arbitrarily we could discover
that we will require an extra year to extricate ourselves from the corner that we
have painted our selves into.

Thomas Dineen



pat_thaler@agilent.com wrote:
Brad,
 
I would think that it is easier to choose a coding scheme once one knows what the channel is.
 
If we choose a coding scheme without knowing the channel parameters then aren't we in a potentially long iterative loop:
 
Choose a coding scheme with a Nyquist frequency of x
Get told the channel parameters to x (or x * (1 + y) to allow for excess bandwidth)
Verify coding scheme operation with that channel
If results not satisfactory, choose new coding scheme, adjust x and y, and repeat.
 
I guess one could avoid the iteration by choosing the higher Nyquist frequency scheme first. Then we would get characterization over the maximum range of operation and knowledgeably adjust our choice if the lower Baud rate looks like a better choice for the channel. But we already asked them to characterize out to 625 MHz and one doesn't want to have to give a coding scheme an advantage over the others by "choosing" it until we know the channel.
 
Pat
-----Original Message-----
From: owner-stds-802-3-10gbt@majordomo.ieee.org [mailto:owner-stds-802-3-10gbt@majordomo.ieee.org]On Behalf Of Booth, Bradley
Sent: Monday, March 01, 2004 8:28 PM
To: stds-802-3-10gbt@ieee.org
Subject: RE: [10GBASE-T] Feedback from ISO/IEC WG 3 meeting

Maybe I should be more specific in my statement.  Knowing the Nyquist frequency of the transmitted symbols on a 10GBASE-T channel would be extremely helpful to ISO/IEC WG 3.  For quite some time we have asked them to characterize the channel out to 625 MHz, but we've also had proposals for a lower frequency of 417 MHz.  The more expediant the Task Force can be on providing specific guidance to WG 3 will help their efforts.  WG 3 only meets twice a year, so early guidance is critical to the feedback we can receive.
 
Cheers,
Brad
-----Original Message-----
From: Thomas Dineen [mailto:tdineen@ix.netcom.com]
Sent: Monday, March 01, 2004 5:46 PM
To: Hugh Barrass
Cc: Booth, Bradley; stds-802-3-10gbt@ieee.org; Thomas Dineen
Subject: Re: [10GBASE-T] Feedback from ISO/IEC WG 3 meeting

GentlePeople:

    In a sense I disagree, while surely we want to agree on key parameters, I think we
need to focus on a set of reasonable parameters which support the end to end solution.
I am concerned that to much focus on nailing down a single key parameter will in effect paint
us into a corner! I would suggest that we instead focus on identifying a set of key parameters
associated with an architectural model which represents an end to end solution. Once these
key parameters are identified we need to then work on identifying a set of compatible parameter
values which support a working end to end solution within the selected architectural model.
The required parameters would include but not be limited to channel bandwidth and characteristics,
coding gain and latency, coding selection and mapping etc.

Thomas Dineen



Hugh Barrass wrote:
Brad,

I agree that the WG should be locking down these key parameters, however the decision on the number of bits per symbol will depend on the coding gain assumed and that will depend on....

latency requirements

... so the discussion that has been running over the reflector needs to be continued and resolved ASAP.

Hugh.

Booth, Bradley wrote:

Dear Task Force members,

I attended the ISO/IEC JTC 1/SC 25/WG 3 meeting last week.  One important point of feedback that I received was if the Task Force could select the number of bits per symbol that would provide a lot more direction to WG 3.  We have been talking about the number of bits per symbol period for over a year, and I believe that it would be prudent of the Task Force to lock that number down.  I would like the Task Force to lock this number down at the March Plenary, so please consider this a request for presentations to support what our decision should be on the number of bits per symbol period.

Thank you,
Brad

Bradley Booth
Chair, IEEE P802.3an Task Force
bbooth@ieee.org
512-732-3924 (W)
512-422-6708 (C)