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

Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call



Jonathan/Brian 

To make the specification work likely we need to adjust some of the knobs: 
- TDECQ equalizer length 
- Reference BW 
- Receiver sensitivity/TX min OMA 

I tend to agree with Brian that we should not be penalizing a well behaved nominal speed MZM that has no energy behind Nyquist on the fear of fast nasty EMLs!  If we had a 5-7 tap FFE + 1 DFE then having 26.55 GHz RX/anti-ailising filter would be OK and the link would deal fine with fast nasty EMLs.  Given that it will be highly unlikely that a DFE will be added, we should not be failing a nominal speed and well behaved transmitter on the fear of nasty fast EMLs because of potential aliasing.  

A real receiver will have some ability to adjust the front end BW, but it may not be practical to implement into the TDECQ software?  So my suggestion is to increase reference EQ BW to ~0.6*Baudrate (32 GHz)
to reduce TDECQ penalty from ~3.5 dB to ~3.00 dB for the nominal transmitter.  Using BW of 0.6*Baudrate may result on some potentially aliasing if you have a fast nasty EML transmitter, but that should get captured  with T spaced TDECQ test.  

Looking at http://www.ieee802.org/3/bs/public/17_05/traverso_3bs_01a_0517.pdf slide 6 indicate with 5 T EQ and 32 GHz BW TDECQ will be ~ 3.0 dB, so we would need to come up with an extra 0.5 dB of sensitivity improvement!


Thanks,
Ali Ghiasi


On Jun 25, 2017, at 8:37 AM, Jonathan King <jonathan.king@xxxxxxxxxxx> wrote:

EMLs ?
 
From: Brian Welch [mailto:bwelch@xxxxxxxxxxx] 
Sent: Thursday, June 22, 2017 9:58 AM
To: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Ali,
I find myself wondering where the above Nyquist content comes from, in the context of your “fast nasty transmitter”. In more discrete transmitter technologies(ie, DML) I could imagine it coming from reflections or such in the packaging, but all of that would exist before the modulation which itself should pretty effectively filter it. In integrated technologies (with higher bw modulators) the driver/modulator interface should be pretty well controlled and such effects should not be present. Unlike copper links once you leave the modulator the relative spectrum should be maintained until you reach the RX (with the possible exception of some small MPI effects).
 
I suppose I don’t disagree that it is possible, but is it probable? When compared with the certain penalty inherent when using a lower BW RX filter is it worth trying to create this anti-aliasing effect?
 
Thanks,
Brian
 
From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxx] 
Sent: Thursday, June 22, 2017 9:47 AM
To: Marco Mazzini (mmazzini) <mmazzini@xxxxxxxxx>; Brian Welch <bwelch@xxxxxxxxxxx>
Cc: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Marco/Brian 
 
Another option is to use variable anti-ailising filter with BW of  [0.5:0.75]*Baudrate.  If you have a well behaved slow MZM with no frequency content beyond Nyquist the anti-ailising filter can be 0.75*Baudrate but if 
you have fast nasty transmitter with frequency content beyond Nyquist then anti-ailising filter is reduced to 0.5*Baudrate.  
 
This is how I expect a well design receiver to operate, the part that I am not sure about if the scope manufacture can build the TDECQ software to operate as such!
 

Thanks,
Ali Ghiasi

 
On Jun 22, 2017, at 9:39 AM, Marco Mazzini (mmazzini) <mmazzini@xxxxxxxxx> wrote:
 
Hi Brian,
one option is to consider that the an ideal TX now has TDECQid = 0.9dB (because the RX receiver reduced BW), so:
 
TDECQdut = TDECQmeas – TDECQid (can be scaled during measurement, it’s a dTDCEQ)
 
So if we take this as valid, in practice there would be no need to change specs with respect draft 3.2 in terms of numbers, just need the addition of a note saying that ‘the TDECQ of the ideal TX is 0.9dB’.
Which by the way I think was one of the comments (maybe from Mike?) during the ad-hoc call.
 
Best regards
Marco
 
From: Brian Welch [mailto:bwelch@xxxxxxxxxxx] 
Sent: jueves, 22 de junio de 2017 18:35
To: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Ali,
The “BW problem” is in how we (most recently) chose the RX filter BW. At 38.9 GHz this does not influence TDECQ, but at 26.55 GHz it does (by ~ 0.8 dB). We are essentially forcing the reference RX to equalize itself in addition to the TX under test, which was not previously the case. This is where we should focus our investigation.
 
Brian
 
From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxx] 
Sent: Thursday, June 22, 2017 9:14 AM
To: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: [PossibleSpam] Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Gary 
 
The fundamental problem we have based on Marco’s results  is that even for 5 T spaced FFE the TDECQ is about 3.4 dB over the current limit of 2.5 dB, effectively we are short of 0.9 dB.  
 
Winston presentation indicates changing the reference EQ form 5 tap to 7 tap T spaced EQ improves TDECQ significantly.  These results all were taken with 38.9 GHz filter, I expect if the
results were taken with 26.55 GHz filter the amount of improvement from 5 taps to 7 taps would improve even more.
 
 
We have a BW problem here and we should be solving the BW issue using an equalizer with sufficient length!   Having more data will help how to better move forward, but going back to the 5 T/2 FFE 
will put us even in worse predicament.  We need to consider 7 T-spaced FFE, increase TDECQ to 3.0 dB, and improve unstressed receiver sensitivity by 0.5 dB.  
 
Forcing TDECQ to 2.5 dB will impact yield and cost of the the transmitter as it was illustrated in Winston presentation.  The worst part is that you end up trowing away good transmitters that exceed the required BER 
when tested with link partner as the commercial receivers have more capabilities than the reference equalizer.  It has been mentioned several times that we should limit the TDECQ filter to 5 taps because analog implementation are limited to 5 taps, here are some references that show longer analog FFE can be implemented
 
9 tap 32 Gb/s FFE filter in Bi-CMOS 
 
7 tap 40 Gb/s FFE in 65 nm CMOS 
 
 
Thanks,
Ali Ghiasi
Ghiasi Quantum LLC
Office (408)352-5346
aghiasi@xxxxxxxxx
<image001.png>
 
On Jun 22, 2017, at 6:52 AM, Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx> wrote:
 
I tend to agree with Carlo. If we are not changing the receiver implementation  (king_01a_0617_smf) then why are we changing the unstressed receiver sensitivity specification ? 
 
Gary
 
Ps. I think there is a typo on slide 7 in Jonathan’s presentation. I believe that the yellow arrow below should also include MPI penalty, i.e. it should be “connector and channel insertion loss + MPI penalty” ?
 
 
 
 
 
 
<image001.png>
 
 
 
 
 
From: "Carlo Tosetti (ctosetti)" <ctosetti@xxxxxxxxx>
Reply-To: "Carlo Tosetti (ctosetti)" <ctosetti@xxxxxxxxx>
Date: Thursday, June 22, 2017 at 8:28 AM
To: "STDS-802-3-400G@xxxxxxxxxxxxxxxxx" <STDS-802-3-400G@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Ciao Mike
 
Please note that, as Brian pointed out, Pete’s tables do show changed unstressed RX sensitivities.
If the power budget is not really changing, I would deem preferable to leave the unstressed RX sensitivity as it is (at the end of the day the SRS of the RX is not changing either, since the RX is the same) with the note that, even if ideal, the reference TX has SECQ = 0.9dB (pending Jonathan confirmation, see below).
 
 
My reasoning is as follows: under the assumption that both RX and – of course - reference TX are not changing (what is changing is the methodology for TDECQ and SECQ calculation: let me call the new one TDECQ’/SECQ’), to me it seems you cannot at the same time do the following:
1)                   apply the usual link budget calculations:
(Launch power in OMAouter minus TDECQ) - Channel IL (- MPI) = unstressed RX sensitivity
2)                   keep the unstressed RX sensitivity unchanged
3)                   assume SECQ’ of the reference TX (let me call it SECQ’ref_TX ) equal to 0dB
 
I see a couple of options. Let me rewrite the link budget calculation as follows:
 
(Launch power in OMAouter minus TDECQ) - Channel IL (- MPI) = unstressed RX sensitivity - SECQref_TX
 
When the original definitions applies (where SECQref_TX= 0), you end up with the following numbers
 
-3.5dBm – 3dB (- 0.1dB) = -6.6dBm -0dB = -6.6dBm
 
With the new TDECQ’/SECQ’ methodology the max TDECQ’ is 0.9dB higher, so you may have:
 
a)            SECQ’ref_TX = 0dB Þ (-3.5-0.9) - 3 (- 0.1) = -7.5 - 0
b)            SECQ’ref_TX = 0.9dB Þ (-3.5-0.9) - 3 (- 0.1) = -6.6 - 0.9
 
Option a) requires an improved RX performance and is consistent with the fact that a zero stress TX has 0dB SECQ’. But I find this extra requirement not justified, given the fact that the same considerations in Jonathan’s presentation regarding ‘SRS remaining unchanged’ should also apply here.
Option b) leaves the RX requirement unchanged but assumes that SECQ’ref_TX is actually 0.9dB, something that I am leaving Jonathan to confirm/reject (is the 0.9dB increase constant with stress amount? If not it would be difficult to do the usual elementary math).
Of course we’ll face the drawback/paradox that a TX with ideal properties has a SECQ’ ≠ 0dB.
 
Please correct me if I am wrong…maybe I did not correctly catch what is being proposed.
 
Thanks and regards
Carlo
 
“…non men che saver, dubbiar m'aggrata…” (Inferno - Canto XI)
 
.:|:.:|:. Carlo Tosetti | 
CISCO | TMG Technical Leader|
 
From: Brian Welch [mailto:bwelch@xxxxxxxxxxx] 
Sent: mercoledì 21 giugno 2017 21:02
To: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-400G] [PossibleSpam] Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Mike,
The presentation that Pete referenced (prepared for next weeks Ad Hoc) is proposing to make the unstressed RX sensitivity more stringent by 0.9 dB, and increasing the SECQ for the SRS value by 0.9 dB.
 
Brian
 
From: Dudek, Mike [mailto:Mike.Dudek@xxxxxxxxxx] 
Sent: Wednesday, June 21, 2017 11:03 AM
To: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: [PossibleSpam] Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
The definition for unstressed receiver sensitivity has always been with zero stress.   Saying that SECQ = 0dB clarifies what is meant by zero stress.      It is harder for the Rx to achieve the BER with a SECQ of 0.9dB rather than SECQ of 0dB and we aren’t changing the Unstressed sensitivity  so I don’t understand why you are saying this makes the Rx unstressed sensitivity test harder.
 
From: Carlo Tosetti (ctosetti) [mailto:ctosetti@xxxxxxxxx] 
Sent: Wednesday, June 21, 2017 1:53 AM
To: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Ciao Peter
 
I have a question related to the added text in the notes on unstressed receiver sensitivity “…and is defined for a transmitter with SECQ of 0dB”.
 
Based on such value, the proposed change in TDECQ has an impact on the RX side, as it is captured by the corrections in unstressed sensitivity values: the same RX which was OK with the reference TX when using the old TDECQ definition is now not working anymore with the new TDECQ definition and needs an improvement of 0.9dB in the unstressed sensitivity.
 
I am wondering – but honestly I am not sure if this is physically sound and consistent with the new proposed TDECQ methodology: shouldn’t the note say instead “…and is defined for a transmitter with SECQ of 0.9dB” (admittedly this looks pretty ugly…)?
 
Thanks and regards
Carlo
 
“…non men che saver, dubbiar m'aggrata…” (Inferno - Canto XI)
 
.:|:.:|:. Carlo Tosetti | 
CISCO | TMG Technical Leader|
 
From: Anslow, Peter [mailto:panslow@xxxxxxxxx] 
Sent: martedì 20 giugno 2017 21:47
To: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Matt,
 
I think that the file I have generated for next week’s SMF Ad Hoc should answer your question:
 
Regards,
Pete Anslow | Senior Standards Advisor
43-51 Worship Street | London, EC2A 2DX, UK
Direct +44 2070 125535 
|
 
From: Matt Traverso (mattrave) [mailto:mattrave@xxxxxxxxx] 
Sent: 20 June 2017 04:16
To: Anslow, Peter <panslow@xxxxxxxxx>; STDS-802-3-400G@xxxxxxxxxxxxxxxxx; Jonathan King <jonathan.king@xxxxxxxxxxx>
Subject: RE: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Hi Jonathan,
I’m sorry to have missed the most recent ad hoc where you presented king_01a_0617_smf.  I find myself confused as to what you mean by: “a similar decrease in the OMAouterminus TDECQ spec”.  Can you show an example with what would happen for the TX or RX table for any of the clause 122 PMD’s?
 
I think this all stems from a mixing of terms increase/decrease with negative numbers…
 
Thanks
--matt
 
 
<image002.jpg>
 
Matt Traverso
PRINCIPAL ENGINEER.ENGINEERING
Cisco Systems, Inc.
3700 Cisco Way
SAN JOSE
95134
United States
cisco.com
 
 
 
 
 
From: Anslow, Peter [mailto:panslow@xxxxxxxxx] 
Sent: Tuesday, June 13, 2017 1:12 AM
To: STDS-802-3-400G@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-400G] IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet SMF Ad Hoc conference call
 
Hi,
 
As previously announced, there is an SMF Ad Hoc meeting starting at 8:00 am Pacific today, Tuesday 13 June.
 
Attendees names and affiliations will be taken from the Webex participants list. Please use an e-mail address indicating affiliation when signing in. If you attend via phone only, or if your employer and affiliation are different, please send me an e-mail.
 
I currently have requests for 1 presentation so the draft agenda is:
 
    • TDECQ changes and consequent spec limits                              Jonathan King, Finisar
 
  • Discussion
 
The presentation for this call is on the P802.3bs SMF Ad Hoc web page.
If you have any questions for the presenter(s) after the call, please ask the Ad Hoc Chair for contact details.
 
Peter Anslow from Ciena has invited you to join a meeting on the Web, using WebEx. Please join the meeting 5-10 minutes early so we may begin on time. 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Topic: "P802.3bs SMF Ad Hoc" 

Date & Time: Every 2 weeks on Tuesday, from Tuesday, 13 June 2017, to Tuesday, 27 June 2017 at 16:00, GMT Summer Time (London, GMT+01:00) 

To join web meeting click here: 
https://ciena.webex.com/ciena/j.php?MTID=m8af2937bfb4b6fd299ccb5ee317895fb 

Meeting password: IEEE (please note passwords are case sensitive) 

Teleconference: Provide your phone number when you join the meeting to receive a call back. Alternatively, you can call:
+44-203-4333547  (United Kingdom)
4438636577  (United States)
2064450056  (Canada)
4006920013  (China)
Show global numbers: 
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=7659923550 
Conference Code: 765 992 3550 


Meeting number: 632 000 521 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Additional Notes: 

- To add this meeting to your calendar program click the following link, or copy the link and paste it into your Web browser: 
https://ciena.webex.com/ciena/j.php?MTID=mfc13bf723def2cc42b90e63cc52f8635 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

https://ciena.webex.com
 
Regards,
Pete Anslow | Senior Standards Advisor
43-51 Worship Street | London, EC2A 2DX, UK
Direct +44 2070 125535 
|