|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
MessageBrad,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 xGet told the channel parameters to x (or x * (1 + y) to allow for excess bandwidth)Verify coding scheme operation with that channelIf 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: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of Booth, Bradley
Sent: Monday, March 01, 2004 8:28 PM
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-----GentlePeople:
From: Thomas Dineen [mailto:firstname.lastname@example.org]
Sent: Monday, March 01, 2004 5:46 PM
To: Hugh Barrass
Cc: Booth, Bradley; email@example.com; Thomas Dineen
Subject: Re: [10GBASE-T] Feedback from ISO/IEC WG 3 meeting
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.
Hugh Barrass wrote:
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....
... so the discussion that has been running over the reflector needs to be continued and resolved ASAP.
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.
Chair, IEEE P802.3an Task Force