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

Re: [10GMMF] TP3 noise discussion



Thank you, Tom.  I'm looking at this, too.
 
- Jim McVey
-----Original Message-----
From: Tom Lindsay [mailto:tom.lindsay@CLARIPHY.COM]
Sent: Tuesday, April 26, 2005 10:57 AM
To: STDS-802-3-10GMMF@LISTSERV.IEEE.ORG
Subject: Re: [10GMMF] TP3 noise discussion

FYI, if you change L8 to 1.5 dB for connectors (total insertion loss appears in column C), then call X44 shows ~2 dB for implementation penalty. It's a bit higher because the predicted noise penalty of 0.8 dB is a bit lower than what the earlier budgets allocated.
 
Tom
 
----- Original Message -----
Sent: Tuesday, April 26, 2005 10:36 AM
Subject: Re: [10GMMF] TP3 noise discussion

All -
 
 
I need to run all this past Paul, but here is my initial assessment using this tool. I'm not sure how accurate it is given the many changes since last May, but I suspect it is still the best tool we have.
  • Use Tab 1310_NRZ_10.
  • Change cell P12 to 870 (the effective modal bandwidth given our selected launch conditions). This results in an ISI penalty of 4.52 dB at 300 meters. I have to ask Paul if this is equivalent to PIE-D.
  • RIN is set at -128 dB/Hz, which is what we should be using for the TP3 test for RIN. In column S, you can see that the RIN penalty starts at ~0.1 dB (not 0.4) and increases as the eye closes with distance. It is ~0.3 dB at 300 meters, given the modal bandwidth above.
  • For MN, if Petar thinks 0.5 dB is the right value of penalty, then we can emulate this (with a noise generator at the source) with noise density of -126 dB/Hz.
  • These two noises can be combined into one noise source where Qsq integrates to ~18 (not 11.5). This is equivalent to -124 dB/Hz. The resulting combined penalty is slightly more than 0.8 dB. Fits nicely within earlier budgeting.
    • Note - to get Qsq = 11.5, noise density ~-120 dB/Hz, and the spreadsheet shows this would create a noise power penalty of 3.36 dB! Obviously this would be a problem... Big difference from 0.8 dB.
    • Note - these values may need some minor tweaking to properly accommodate the noise bandwidth of the BT4 filter, which is 4.7% higher than the 3 dB bandwidth.
 
Comments?
Tom
 
 
----- Original Message -----
Sent: Tuesday, April 26, 2005 7:56 AM
Subject: Re: [10GMMF] TP3 noise discussion

Hi Albrecht - see within.
 
I've copied this onto the reflector.
 
Tom
 
----- Original Message -----
Sent: Tuesday, April 26, 2005 2:57 AM
Subject: TP3 noise discussion

Hello Tom,

For today's TP3 call, Jim asked us to look at the noise
calculation again. Therfore, I would like to share my
thoughts on this topic with you. May be I am missing
something completely, which is the reason why I am
sharing my thoughts with you and not sending them
directly to the LRM reflector.

Our main concern about the TP3 SNR definition is

that we don't see the relationship between the link budget
and the SNR calibration as currently defined by the Qsq ratio
of 11.5 in the LRM draft.
 
Regarding the link budget, the LRM community is assuming a
reference SNR at the input to the EDC of 30dBe (17+2x6.5).
This value is used for TWDP calculations and for PIE-D
coverage work and assumes a reference channel without ISI
but with RIN and MN penalties.
TL - this particular calculation (for TWDP) does not include RIN or MN. It is based on a matched filter bound receiver that provides -13 dBm optical sensitivity to a perfect rectangular waveform. The min received OMA is -6.5 dBm, so the difference is 6.5 dB (and hence, the value in the equation).
Having written this, I think the value may have a problem. Perhaps the SNR without these terms should be 32 dBe. The latest budgets (see Nov 04) show sensitivities at ~-14 dBm (not -13), required to accommodate 1 dB of penalties due to RIN and MN!
 
For the TP3 SNR calibration, the value of Qsq is
derived from 0.9dBo noise power penalty. Even Piers
pointed out in dawe_1_0504 that the contribution from
MN of 0.5dB is pessimistic as it was defined
for GbE where the exact value did not matter and OFL was
used. We further noticed that a slight change from 0.9 to 1.0dBo
will have a large impact on Qsq (11.5 to 12) and the resulting SNR.
TL - the penalties were set at 0.5 and 0.4. They are independent and assume no other simultaneous noises. These cannot be simply added when computing penalties. Mathematically, they combine to 1.0 dB. The math is right, but if the values for the individual terms are too high, then we should lower them (which will reduce the combination).
 
The SNR corresponding to Qsq=11.5 is 20log11.5 = 21.2dBe
Using Lew's assumption of -3dBo noise coloring due to IFR,
this improves the SNR at the optical receiver input to about
27.2dBe
. Assuming a reciever sensitivity of -14dBm and an OMA
of -6.5dBm, this results in a SNR at the
EDC input of about 25.8dBe,
which is significantly
below the 30dBe reference SNR derived
from the link budget.
To make the link budget and the Qsq approaches
match, you would
need to reduce MN+RIN or increase IFR.
Should these match at all?
TL - I do think there is a problem. For example, the RIN spec produces Qsq = ~29 at TP2. MN may bring it down further, maybe ~20 - not 11.5.  0.5 and 0.4 came from experience at 802.3ae, where an overall Qsq on the order of 20 produces penalties in the overall budget of 1 dB due to interactions with other impairments, mostly ISI closure. We should not be starting with 1 dB, but ending there. Now, there is the question of whether any of these are the right values for 802.3aq! Perhaps the 29 factor is fine for RIN at TP2, and perhaps 0.4 dB for MN is okay (at TP3, not a TP2), but the interaction with all the dispersion is not well understood. That's the rub here. Paul Voois did some early spreadsheet work on RIN, and that work should be revisited. See http://grouper.ieee.org/groups/802/3/aq/public/may04/voois_1_0504.pdf. I'll try to take some time to look at this work.
 
Finally, I wonder why we can ignore jitter during the stress test,
when we needed to apply it for 10G-Base-LR .
TL - if we reduce the noise, we may need to add some jitter back in, although the added complexity is not desirable. Currently, the noise is high, so no added jitter is needed.
-- 
Best regards,

Albrecht Rommel
Acuid Corporation Ltd.
Phone  +49 (0)8141 3555 813
Fax    +49 (0)8141 3555 829
Mobile +49 (0)172 607 8039
albrecht.rommel@acuid.de
www.acuid.com