Re: [10GBASE-T] Feedback from ISO/IEC WG 3 meeting
Pat,
The channel parameters are essentially fully described. (except for
alien ELFEXT).
The primary parameters are equivalent to Class E extended to whatever
maximum frequency is necessary.
The installed base PSANEXT roughly equivalent to data presented by Shadi
AbuGhazaleh.
This is the objective agreed to for at least 55 meters. These numbers
have not been objected to in the cabling community, and, while not fully
vetted, are gaining a de-facto acceptance.
For augmented cabling parameters, the insertion loss will be extended to
100 meters and the PSANEXT to insertion loss ratio adjusted to achieve
similar capacity calculations. (taking into account whatever parameters
deemed necessary by the Task Force) One option is to improve the
insertion loss to Class F level (or slightly better) to make the PSANEXT
requirement as lenient as possible. Don't look for any big gains here,
as the practical limit is essentially determined by a wire gauge of 22 AWG.
For capacity calculations, the bandwidth of integration is a primary
parameter, so it is difficult to come up with a hard and fast estimate
of the AXTIR without at least knowing this parameter. I would suggest
choosing a coding scheme that minimizes the PSANEXT requirement, but
there may be other factors that override this, such as the practical
bandwidth of signal transformers.
So for estimating purposes, the cabling parameters are known. The
PSANEXT specifications for 100 meters will simply be set at whatever
they have to be to make it work. The cable and connector manufacturers
will come up with practical methods to achieve them.
Sterling Vaden
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)
>>>
>