Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: STDS-802-3-10GBT@LISTSERV.IEEE.ORG*Subject*: Re: [10GBT] Issues with solarsep_varlen7a.m*From*: George Zimmerman <gzimmerman@SOLARFLARE.COM>*Date*: Thu, 8 Jul 2004 09:24:49 -0700*Reply-To*: "IEEE P802.3an" <STDS-802-3-10GBT@LISTSERV.IEEE.ORG>*Sender*: stds-802-3-10gbt@IEEE.ORG*Thread-Index*: AcRk/VQkE7NfmrAgROieVPhjba1ntQABggIA*Thread-Topic*: [10GBT] Issues with solarsep_varlen7a.m

Glen - Thanks for a good description of the key difference. The optimal DFE result includes optimization of filtering prior to baud sampling as well as any baud spaced FFE. As you point out, the folded SNR result is NOT, as Sailesh asserts, limited to T/2 spaced FFE systems (that is just one way of implementing the optimality for the first fold). It is well known in practice that the SNR on limiting cases can be optimized by tuning the front end filter. On the other hand, the MMSE analysis that Sailesh is assuming assumes NO front end filtering prior to baud sampling, and, therefore is inherently pessimistic. Such a design would suffer from aliased noise. Any real system would have a filtering prior to baud sampling. If we were to assume a front-end filter function, why not assume an optimal design to get best performance? This leads us right back to the optimum folded SNR relation of the DFE found in the code. As you also point out, the argument that Sailesh is making is a small one. If I eliminate the folding entirely, the absolute DFE SNR results change between approximately 0.1 and 0.2 dB, and the relative values (2 vs. 2.5 vs. 3 bits/baud/pair PAM) change by 0.1 dB. Sailesh - I hope this answers your folded SNR question. On your question on the March presentation, I'm not sure which parameters you have in question, but if you give me a call, I'll be happy to look up whatever information you're missing. The SNR comparison is generated as margin relative to capacity, which is scaled relative to 6.02 dB/bit/baud/pair. This can be found in lines 470-494 of the code, not the section you were commenting on. The channel model used is stated in the presentation. Previous emails with Samir on the reflector have clarified the command-line parameters that correspond to our now-agreed Models 1 2 & 3. (careful - I recall the first part of the exchange had a sign error). A result similar to those from March can be found on Slide 5 of mclellan_1_0504, except this one is now for our agreed channel model #1. I will also point out that the optimality of the lower baud rates is for both the longer channels, and that it has been independently presented in takatori_1_0504 and Ungerboeck_1_0504, and, at the latter analysis (Ungerboeck) comes at the problem from a completely different perspective. -george -----Original Message----- From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On Behalf Of Glenn Golden Sent: Thursday, July 08, 2004 8:02 AM To: STDS-802-3-10GBT@listserv.ieee.org Subject: Re: [10GBT] Issues with solarsep_varlen7a.m > > Sailesh Rao <saileshrao@OPTONLINE.NET> writes: > > > > The folded SNR calculations in lines 443, 453 and 463 are not right. > > > > If f1 and f2 are mirror frequencies about fs/2, the formula being > > used > > > is > > > > S/N = ABS(S1/N1) + ABS(S2/N2) ; > > > > However, the actual SNR at the folded frequency would be > > > > S/N = ABS(S1+S2)/ABS(N1+N2) > > > > where S1, S2, N1, and N2 are complex phasors. Therefore, in the > > context of folding, the actual PSD of the signal becomes relevant, > > whereas the original Salz formula for the optimum DFE SNR is > independent of the PSD. > > > George Zimmerman <gzimmerman@SOLARFLARE.COM> writes: > > > > On the folded SNR calculation, however, you are incorrect. The > > optimum DFE is based on a folded SNR which is the sum of the SNRs, > > not > > > the sum of the signal over the sum of the noise. You can check > > either > > > Salz, or for a more direct representation, please check Pottie & > > Eyuboglu, JSAC, August 1991, equation 6. > > > The Salz DFE analysis assumes a prefilter prior to the baud sampler. Following optimization (in AWGN) the prefilter turns out to be equivalent to the cascade of a channel matched filter followed by a one-sided synchronous tapped delay line. The matched filter's phase (conjugate to channel) ensures that the net transfer function (channel*MF) lies on the positive real axis prior to the baud sampler. Thus, all folding translates (f0+k/T, k = -inf ... inf) add unidirectionally, eliminating the effects of channel phase. It is only because of this phase alignment that the optimized integrand involves the sum-of-SNRs, and not sum-of-signal/sum-of-noise. (The same holds for a DFE with fractionally spaced FFF.) But for a synchronous DFE in the absence of a matched filter -- probably the system of interest to most of us -- no special phase alignment of the translates can be assumed, and the relevant folding expression (for flat AWSS noise with variance N0) is abs(SUM H(f0+k/T)) ** 2 / N0 , k H(f) being the net transfer function from the Tx to the Rx baud sampler input. Except for a missing "**2", this is essentially as Sailesh indicated. The bottom line is that without a MF or fractionally spaced FFF, the value of the summation depends on the channel and front-end phases at the translate frequencies, which is the point I believe Sailesh was making. The sum-of-SNRs folding is an upper bound. Thus, the solarsep code yields optimistic results, unless the assumed system model includes a fractionally spaced or MF front end. For our channel, as long as the rolloff is smooth, the 'optimism' will not be very large, because even if translates are completely out of phase, the in-band translate magnitudes dominate. Similarly if the front-end rolls off reasonably above 1/(2Fs). But if there are large ripples near 1/(2Fs) and shallow front-end rolloff, then significant dips in the folded spectrum can be introduced which could result in non-negligible MSE differential between the solarsep method and a more realistic (synchronous, no MF) evaluation. Glenn Golden Principal Engineer Teranetics, Inc.

**Follow-Ups**:**Re: [10GBT] Issues with solarsep_varlen7a.m***From:*Glenn Golden <gdg@zplane.com>

- Prev by Date:
**Re: [10GBT] Issues with solarsep_varlen7a.m** - Next by Date:
**Re: [10GBT] Issues with solarsep_varlen7a.m** - Prev by thread:
**Re: [10GBT] Issues with solarsep_varlen7a.m** - Next by thread:
**Re: [10GBT] Issues with solarsep_varlen7a.m** - Index(es):