| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Jonathan, Can I ask what perspective are you making your statement from regarding sufficient cost, power, or size, to justify another PMD spec. Would you consider it to be the sorts of deployments you see associated with optics today or with high volume manufacturing? I ask this, because I remember back in the early days of Backplane Ethernet when people argued over the cost associated with counterboring. I remember saying many times that a certain company had imprinted the letters HVM into my forehead. John From: Jonathan King [mailto:jonathan.king@xxxxxxxxxxx] Hi Brad, Thanks for comments ! Ryan and I just compared the proposals for MMF PMDs that have been contributed to 802.3bm, with (for myself at least) a very module-centric viewpoint, to see how our project goals of significant reduction of cost, power, or size, would be addressed by the un-retimed PMD proposal. Slide 2 was intended to provide a short summary of the context of the comparison, it refers to the 100 m reach MMF PMD baseline proposal, which makes it clear that CAUI-4 is an example (not a required) 4 lane interface. I’m happy to add an explicit reference to that baseline if that helps ? Whether the implementer uses CAUI-4 or not, for the PMD specs to be viable, modeling shows that there are very tight jitter requirements at the PMA/PMD interface; putting retiming inside the module is one way of making that so (for the 100m reach baseline). I agree there may be many proprietary methods for meeting the optical specs for the 802.3bm 100m MMF PMD – but Ethernet doesn’t disallow any of those by not standardizing an un-retimed interface - it is a given that proprietary solutions meeting the PMD specs are allowed and expected. But if even they could allow use of a module without retiming, it’s not going to save sufficient cost, power, or size, to justify another PMD spec. Best wishes jonathan From: Brad_Booth@xxxxxxxx [mailto:Brad_Booth@xxxxxxxx] Jonathan, I want to touch on your statement that the “PMA is expected to be inside the module.” That is my primary concern. IEEE P802.3bm does not specify modules, nor does it specify implementations. CAUI-4 is an OPTIONAL instantiation of the PMA service interface. The use of CAUI-4 as the interface to an optical module or for any other means is an implementation decision. While the presentation is correct relative to a very specific implementation using CAUI-4 optical modules, there is a potential market that is being ignored by assuming they will use CAUI-4 and/or an optical module. Would you (and your supporters) be willing to add clarification to the presentation that the material assumes the use of a CAUI-4 optical module and other implementations could result in different cost, power and size estimates? Thanks, From: Jonathan King [mailto:jonathan.king@xxxxxxxxxxx] Hi Brad, Thank for your comments. You are right, the clock and data recovery are part of the PMA; for the 100G 100m MMF baseline that part of the PMA is expected to be inside the module. You raise an interesting point about having different power settings controllable by management software – my initial thoughts are that the difference between 20m and 100m reach link budgets is about 1.4 dB, it’s probably not very significant in terms VCSEL bias current savings for example. I don’t think CDRs could be turned off without tighter jitter specs being set at the electrical interface - as some of John Petrilla’s work has shown in the MMF ad hoc meetings, the chip to module CAUI-4 specs don’t support an un-retimed optical link. John’s work showed that 20 m reach PMD optical parameters would need to be as tight as the 100m baseline in order to make the jitter specs achievable. Of course, I’m happy to hear other opinions Best wishes jonathan From: Brad_Booth@xxxxxxxx [mailto:Brad_Booth@xxxxxxxx] Jonathan, Thanks for forwarding the presentation. There is one aspect that does concern me as I reviewed the material and that is it is only making a comparison of unretimed vs. retimed implementations. As far as my understanding of a PMD and its PMD service interface, there are no clock and data recovery circuits (see Annex 86A). Therefore, I think the presentation has not really focus on the differences that could be specified relative to the PMDs. I’m not an optics expert, so please feel to correct my following interpretation/thought-line. It would seem to me that the Task Force could specify different optical power requirements (one for 20m and another for 100m) that could be controlled via the management interface. The 100m power level would be the default, and the 20m power level could be selected by either management software or the end user. Would this scenario offer any potential power savings? Thanks, From: Jonathan King [mailto:jonathan.king@xxxxxxxxxxx] Dear all, Following a couple of comments, I’ve revised the slides slightly to be more clear that those listed as supporters (or detractors) are supporting the conclusions, rather than necessarily 100% agreeing with the specific details in the presentation . Obviously power estimates vary somewhat between companies. I’ve moved the supporters and detractors lists to the end of the presentation and labeled them as ‘supporting the conclusions’ and ‘not supporting the conclusions’ . Best wishes jonathan From: Jonathan King <jonathan.king@xxxxxxxxxxx> Dear all , Ryan and I are seeking supporters and detractors for the attached joint presentation: “Cost, power, size differences of proposed MMF PMDs: 20 m reach un-retimed vs 100 m reach retimed baseline”, which will be submitted for to the May meeting of 802.3bm in Victoria, BC. The slides conclude that “• By about the same time 802.3bm is technically stable (H2 2014) there will be no significant power, cost, or size, advantage to be gained from an un-retimed short reach PMD. – A 20 m reach un-retimed PMD would not meet the criteria for distinct identity. • The 20 m reach objective is met by the 100 m reach PMD, a separate 20 m PMD is not required” If you agree (or disagree) with the presentation and wish to be listed as a supporter (or detractor) of the presentation, please let me know by e-mailing me. Thanks ! Best wishes jonathan |