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

Re: [10GBT] THP coefficient set clarification & robustness

We've been looking at several lines, that have taken us some fair amount
of effort to accumulate.  After we've gotten the coefficients that
people are proposing for the standard, and have verified the results, we
may post some of the line measurements as an example.  First, however,
we'd like to get the proposed coefficients verified, without typos.  Do
you have them, and do you have them working on any of the line models
already posted?  If so, that would be a step in the right direction.

-----Original Message-----
From: Glenn Golden []
Sent: Friday, January 07, 2005 7:26 PM
To: George Zimmerman
Subject: Re: [10GBT] THP coefficient set clarification & robustness

Hi George,

Would you be able to post your measured line data to the reflector?
We'd like to have a look at the issue you're raising, and want to
make sure we're using the same channel data.


Glenn Golden
Principal Engineer
Teranetics, Inc.

George Zimmerman writes:
> Gottfried (& others) -
> If you could put forward your preferred set of coefficients for the
> on long lines, I would like to double check our simulations.  With the
> coefficients that were in your presentation, we are generally seeing
> MUCH worse results than you presented (using measured line models
> than your analytic models), and would like to check that we're using
> right forms. I want to make sure that what we're seeing here is not
> result of a "typo".
> When I look at other results, for example, Albert's posting,  the loss
> in performance due to the mismatch of a small set of THP coefficients
> relative to the actual impulse response is appearing significant - as
> Albert has pointed out.
> If this continues to be the case, Seki's earlier proposal
> (seki_1_0504.pdf) of an HDSL2-like coefficient exchange at startup
> fixing the coefficients) is becoming a more attractive alternative.
> limiting the THP to a small set saves little hardware relative to the
> chip size, and seems to account for a significant robustness risk (at
> the least), or a much larger part of the performance margin budget
> the hardware necessary to fix it would engender.
> =20
> -george