Re: [STDS-802-3-25G] 25G CR objective wording
Or even a new MDI. The 30dB no FEC was with something like Whisper connectors.
Sent from my iPhone
> On Aug 21, 2014, at 8:17 PM, "Chalupsky, David" <david.chalupsky@xxxxxxxxx> wrote:
>
> You said works with FEC, right?
> Can we treat IL budget repartitioning and FEC/no-FEC as independent issues?
> I think it's still interesting to save the PCB cost even if FEC is still needed.
> ,,,another debate that could wait for TF...
>
> -----Original Message-----
> From: Mellitz, Richard [mailto:richard.mellitz@xxxxxxxxx]
> Sent: Thursday, August 21, 2014 4:50 PM
> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-3-25G] 25G CR objective wording
>
> Works = Exceed COM limit.
> Loss is not the only factor. I would differ to the folks who did the posting on the details.
> ... Rich
>
>
>
> Sent from my iPhone
>
>> On Aug 21, 2014, at 7:39 PM, "Vineet Salunke (vineets)" <vineets@xxxxxxxxx> wrote:
>>
>> Richard,
>>
>> What is the cable assembly loss (and gauge) for these "posted" 3m cables ?
>> When you say did not work, is that channel modelling, serdes simulation, or lab testing ?
>>
>> Loss for 3m cable @ 3.5 dB/m @ 26 AWG = 10.5 dB.
>> add 2 dB for each connector.
>> cable assembly loss = 14.5 dB.
>> add 6.5 dB for each host.
>> total 27.5 dB. (can be even lower, if using thicker gauge, eg: 24 AWG).
>>
>> --vineet
>>
>> -----Original Message-----
>> From: Mellitz, Richard [mailto:richard.mellitz@xxxxxxxxx]
>> Sent: Thursday, August 21, 2014 4:27 PM
>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
>> Subject: Re: [STDS-802-3-25G] FW: [STDS-802-3-25G] 25G CR objective wording
>>
>> I have not really got the posted 3 meter cables to work without FEC. If folks think they can build a better cable and still have it work mechanically I'd go with A.
>> ... Rich
>>
>> Sent from my iPhone
>>
>> On Aug 21, 2014, at 5:44 PM, "Chalupsky, David" <david.chalupsky@xxxxxxxxx<mailto:david.chalupsky@xxxxxxxxx>> wrote:
>>
>> I like A. Simple, clear... doesn't leave an end-user wondering what the reach will be.
>> This also forces the conversation on reach now. If anyone objects to 3m, better speak up!
>>
>> If there is disagreement on the reach, then C allows for possible repartitioning in TF.
>>
>> dlc
>>
>>
>> From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
>> Sent: Thursday, August 21, 2014 2:01 PM
>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx>
>> Subject: Re: [STDS-802-3-25G] FW: [STDS-802-3-25G] 25G CR objective wording
>>
>> I'd say a, then c, based on simplicity. B is a mouthful, and i don't know what it means to reuse characteristics. Thanks to all, for the discussion, I think things are getting clearer.
>>
>> George A. Zimmerman
>> CME Consulting, Inc.
>> Experts in PHYsical Layer Communications
>> 310-920-3860
>> george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>>
>>
>> Mark Gustlin <mark.gustlin@xxxxxxxxxx<mailto:mark.gustlin@xxxxxxxxxx>> wrote:
>> I vote for A. I think simplicity is good.
>>
>> Mark
>>
>>>> -----Original Message-----
>>>> From: Mellitz, Richard [mailto:richard.mellitz@xxxxxxxxx]
>>>> Sent: Thursday, August 21, 2014 1:26 PM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx>
>>>> Subject: Re: [STDS-802-3-25G] 25G CR objective wording
>>>>
>>>> I cast my vote for C.
>>>> ... Rich
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Aug 21, 2014, at 3:58 PM, "Mark Nowell (mnowell)"
>>>> <mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx%3cmailto:mnowell@xxxxxxxxx>>> wrote:
>>>>
>>>> Thanks Vineet,
>>>>
>>>> I see we are trying to balance simplicity of the language of the
>>>> objective, clarity on what the task force will do, and enabling the
>>>> task force to not be unable from exploring what it may want to do.
>>>>
>>>> The things I believe I'm hearing are definite "musts" are a reach of
>>>> at least 3m and the re-use of the existing transceivers designed for
>>>> 802.3bj implementations. I also believe we have interest to not
>>>> preclude the Task Force to be able to explore host board and cable
>>>> loss budget allocations (but not the overall loss budget!).
>>>>
>>>> So I'm proposing a series of objectives for the twin-ax objective
>>>> which I believe all essentially say the same thing. But with a
>>>> different balance point between simplicity of language and
>>>> clarity/preciseness. I'd appreciate feedback on the these:
>>>>
>>>> A) Define a single lane 25 Gb/s PHY for operation over links consistent with
>>>> copper twin axial cables, with lengths up to at least 3m (same language as
>>>> 802.3bj - with a different reach #)
>>>>
>>>> B) Define a single lane 25 Gb/s PHY for operation over links
>>>> consistent with copper twin axial cables, with lengths up to at least
>>>> 3m that re-uses the host board silicon transmitter and receiver
>>> characteristics specified in IEEE Std
>>>> 802.3bj-2014 Annex 92A (adding reference to the receiver and
>>> transmitter
>>>> specs - I know they are defined in Clause 93, bust Annex 92A
>>>> references them and this provides consistency with twin-ax clauses)
>>>>
>>>> C) Define a single-lane 25 Gb/s PHY for operation over copper
>>>> twin-axial cables consistent with the overall channel budget specified
>>>> in IEEE Std
>>>> 802.3bj-2014 Clause 92
>>>>
>>>> I personally lean to simplicity, so would choose A, then B, then C
>>>>
>>>> Feedback?
>>>>
>>>> Regards...Mark
>>>>
>>>> On 8/20/14, 9:05 PM, "Vineet Salunke (vineets)"
>>>> <vineets@xxxxxxxxx<mailto:vineets@xxxxxxxxx<mailto:vineets@xxxxxxxxx%3cmailto:vineets@xxxxxxxxx>>> wrote:
>>>>
>>>> Team ...
>>>>
>>>> Thanks to David and Matt for providing some clarity here.
>>>>
>>>>
>>>> 1) We want to constrain the total loss budget (or end to end channel) or
>>> to
>>>> be compatible with 100G CR4 transceivers.
>>>>
>>>> 2) We want to allow task force the opportunity to re-partition the loss
>>>> budget between host and cable, to meet the market needs.
>>>>
>>>> Some examples we have heard - avoid use of FEC, allow for larger host
>>>> loss, target for 3m cables (not 5m).
>>>>
>>>> Are there any strong objections to Steve's suggestion of keeping it
>>>> simple and high level ?
>>>>
>>>> * Define a single lane 25 Gb/s PHY for operation over links consistent
>>> with
>>>> copper twinaxial cables, with lengths up to at least 3m.
>>>>
>>>> --vineet
>>>>
>>>> From: Matt Brown (APM) [mailto:mbrown@xxxxxxx]
>>>> Sent: Wednesday, August 20, 2014 5:11 PM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Hi Steve,
>>>>
>>>> The intent of the posted proposed objective is to indicate that the
>>>> 25G Ethernet copper cable PHY is not to start from a blank slate, but
>>>> rather is constrained to permit end users and suppliers to leverage
>>>> technology developed for 100GBASE-CR4, e.g., transceivers.
>>>>
>>>> The expressed concern with the posted proposed objective is that it
>>>> might be interpreted to be too restrictive and may not allow any
>>>> non-obvious deviations; e.g., must use the host loss budget as
>>>> specified in 802.3bj. As an example, Vineet's presentation yesterday
>>>> proposed an additional host configuration restricted to around half
>>>> the 802.3bj host budget with cable lengths up to 3 m that might allow
>>>> no FEC or lower latency FEC (e.g., Clause
>>>> 74) and meet BER/MTTFPA targets.
>>>>
>>>> The intent is to find words that will not be interpreted as being that
>>>> restrictive. Chris's suggested wording is intended to clarify that the
>>>> channel specifications referred to in the objective are the end to end
>>>> (TP0 to TP5) parameters, not necessarily the partitioning of the
>>>> budget. This would constrain the end to end channel to be compatible
>>>> with 100GBASE-CR4 transceiver technology but would permit
>>>> repartitioning of the channel budget between transceivers amongst other
>>> trade-offs.
>>>>
>>>> Matt Brown
>>>> AppliedMicro
>>>> mbrown@xxxxxxx<mailto:mbrown@xxxxxxx><mailto:mbrown@xxxxxxxx>
>>>> 613 254 6728 office
>>>> 613 852 6728 cell
>>>>
>>>> From: Trowbridge, Stephen J (Steve) [mailto:steve.trowbridge@ALCATEL-
>>>> LUCENT.COM<http://LUCENT.COM><mailto:steve.trowbridge@xxxxxxxxxxxxxxxxxx>]
>>>> Sent: Wednesday, August 20, 2014 6:22 PM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Hi David,
>>>> Certainly fine to have that discussion to prepare for the task force,
>>>> but no need to put any constraining details in the objective. If you
>>>> think you might want to change stuff in this way, and a shorter reach
>>>> meets the market need, you could back the objective off to "at least
>>>> 3m" or "at least 4m" and leave yourself that flexibility. Even if you
>>>> later decide to just copy what bj did, the bj solution meets "at least 3m"
>>> and "at least 4m".
>>>> Regards,
>>>> Steve
>>>>
>>>> From: Chalupsky, David [mailto:david.chalupsky@xxxxxxxxx]
>>>> Sent: Wednesday, August 20, 2014 4:11 PM
>>>> To: Trowbridge, Stephen J (Steve); STDS-802-3-
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: RE: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Steve - we have been discussing repartitioning the end-to-end budget
>>>> for CR... Maybe reduce the cable length & give some back to the host PCB
>>>> channel segment... so if we are going to put a reach objective in for CR
>>>> we need to finish that debate first. The other suggestions for CR
>>>> objective wording kept things vague enough that we could work the
>>> partition later.
>>>>
>>>>
>>>>
>>>> From: Trowbridge, Stephen J (Steve) [mailto:steve.trowbridge@ALCATEL-
>>>> LUCENT.COM<mailto:steve.trowbridge@ALCATEL-%0b%3e%20%3e%20LUCENT.COM>]
>>>> Sent: Wednesday, August 20, 2014 3:02 PM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Hi all,
>>>> I think you guys are getting into the weeds here considering that this
>>>> is the Study Group phase. I believe that the objectives can be much
>>>> higher level than you are proposing and you can trust the task force
>>>> to do the right thing, because this isn't a waterfall thing where you
>>>> are creating a set of objectives and throwing them over the fence to a
>>>> totally disjoint group of engineers who you don't trust to do the
>>>> right thing unless you tie their hands: the task force will be YOU, and if you
>>> can't trust yourself, who can you trust?
>>>>
>>>> The only reason the later iteration of the P802.3bj objectives got
>>>> into channel details was that they were trying to generate distinct
>>>> identity for doing two backplane PHYs, otherwise they could just have
>>>> left it as "up to 1m over a backplane".
>>>>
>>>> Assuming you are intending to specify a single backplane PHY rather
>>>> than having KR and KP variants, I think you could leave it as:
>>>>
>>>> * Define a single lane 25 Gb/s PHY for operation over links consistent
>>> with
>>>> copper traces (as specified by P802.3bj) with lengths up to at least 1m.
>>>>
>>>> * Define a single lane 25 Gb/s PHY for links consistent with copper
>>>> twinaxial cables with lengths up to at least 5m.
>>>> Regards,
>>>> Steve
>>>>
>>>> From: Vineet Salunke (vineets) [mailto:vineets@xxxxxxxxx]
>>>> Sent: Wednesday, August 20, 2014 12:18 PM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Matt,
>>>>
>>>> I agree, staying with CR4 specs would be best, but I am trying to
>>>> understand the need for larger host loss.
>>>>
>>>> The main volume would be "SFP" ports used on both switch and server,
>>>> so we should optimize for that.
>>>> QSFP switch ports will not be able to use the larger loss, but can
>>>> still provide 4x25G CR breakout.
>>>>
>>>> --vineet
>>>>
>>>> From: Matt Brown (APM) [mailto:mbrown@xxxxxxx]
>>>> Sent: Wednesday, August 20, 2014 10:43 AM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Hi Vineet,
>>>>
>>>> I think it makes a lot of sense to retain the 802.3bj host loss. The
>>>> case in point would be a switch with 4x25G connectors that may be used
>>>> for either a signal 100G Ethernet port (100GBASE-CR4 per 802.3bj) or
>>>> four 25G Ethernet ports (25GBASE-CR per new 25G project).
>>>>
>>>> Matt Brown
>>>> AppliedMicro
>>>> mbrown@xxxxxxx<mailto:mbrown@xxxxxxx><mailto:mbrown@xxxxxxxx>
>>>> 613 254 6728 office
>>>> 613 852 6728 cell
>>>>
>>>> From: Vineet Salunke (vineets)
>>>> [mailto:vineets@xxxxxxxxx<mailto:vineets@xxxxxxxxx<mailto:vineets@xxxxxxxxx%3cmailto:vineets@xxxxxxxxx>>]
>>>> Sent: Wednesday, August 20, 2014 12:08 PM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Chris,
>>>>
>>>> We heard on the call yesterday, at least 3 demands that do not exactly
>>>> match Clause 92.
>>>>
>>>> * Need to reduce the host loss on the server side, to reduce total loss
>>> and
>>>> avoid use of FEC.
>>>>
>>>> * Need to further optimize around 3m cables for above.
>>>>
>>>> * And I also heard need to allow larger host loss for the TOR switch side
>>>> (when using RS-FEC).
>>>>
>>>> So can we avoid the direct reference to Clause 92 specifications ?
>>>>
>>>> --vineet
>>>>
>>>> From: Christopher T. Diminico [mailto:00000025925d7602-dmarc-
>>>> request@xxxxxxxx<mailto:request@xxxxxxxx>]
>>>> Sent: Wednesday, August 20, 2014 8:57 AM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Rich,
>>>>
>>>> Hopefully this addresses both you and George.
>>>>
>>>> Given the intent is to operate over channels consistent with the
>>>> channel
>>>> (TP0-TP5) specified in IEEEStd802.3bj-2014 Clause92.
>>>>
>>>> *Define a single-lane 25Gb/s PHY for operation over channels
>>>> consistent with the channel specified in IEEEStd802.3bj-2014 Clause92
>>>> (Fig 92-2 - TP0-TP5) Regards, Chris DiMinico
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Mellitz, Richard
>>>> <richard.mellitz@xxxxxxxxx<mailto:richard.mellitz@xxxxxxxxx<mailto:richard.mellitz@xxxxxxxxx%3cmailto:richard.mellitz@xxxxxxxxx>>>
>>>> To: STDS-802-3-25G <STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-
>> <mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-%0b>> 802-
>>>> 3-25G@xxxxxxxxxxxxxxxxx<mailto:3-25G@xxxxxxxxxxxxxxxxx>>>
>>>> Sent: Wed, Aug 20, 2014 11:49 am
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder Both suggestions allude to a
>>>> specific host/module budget which I believe needs to re-evaluated in task
>>> force.
>>>> Perhaps:
>>>>
>>>> Define a single-lane 25Gb/s PHY for operation over copper twin-axial
>>>> cables, host channels, and module channels consistent with channels
>>>> (TP0-TP5) specified in IEEEStd802.3bj-2014 Clause93
>>>>
>>>> This sort of reinforces a single silicon solution.
>>>>
>>>> From: George Zimmerman
>>> [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx<mailto:george@C
>>>> MECONSULTING.ONMICROSOFT.COM?><mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx%3cmailto:george@C%0b%3e%20%3e%20MECONSULTING.ONMICROSOFT.COM?%3e>]
>>>> Sent: Wednesday, August 20, 2014 10:33 AM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Chris -
>>>> Clause 92 has a lot of non-channel stuff in it, and the parenthetical
>>>> insert, while clarifying to those who know clause 92 intimately, isn't
>>>> perhaps as clear as you could be. Pointing to the correct subclause,
>>>> a figure or a table would be a lot better.
>>>>
>>>> The wording itself leads to confusion because it says "over copper
>>>> twinaxial cables consistent with", but TP0 to TP5 includes more than
>>>> the twinax cables, as you know. We end up with a couple of choices:
>>>> 1) Just identify the cables in clause 92, or
>>>> 2) Say operate over the whole TP0 to TP5 channel in clause 92
>>>> (I apologize because I have another call which conflicted with
>>>> yesterday's meeting - I don't have an opinion on whether using the
>>>> whole channel from
>>>> TP0 to TP5 is in fact the correct objective, or whether you want to do
>>>> just the
>>>> cables) If you just want to do (1) just the cables, the cable assembly
>>>> is specified in 92.10 (and references elsewhere), I would suggest
>>>> stating *Define a single-lane 25Gb/s PHY for operation over copper
>>>> twin-axial cables consistent with cable assemblies specified in
>>>> IEEEStd802.3bj-2014 Clause92.10
>>>>
>>>> And, if you want to do the whole channel, including the PCB, as you
>>>> stated, from TP0 to TP5, Clause 92.9 clearly specifies this (by
>>>> referencing other
>>>> subclauses)
>>>>
>>>> *Define a single-lane 25Gb/s PHY for operation over copper twin-axial
>>>> cables consistent with cable assemblies specified in
>>>> IEEEStd802.3bj-2014 Clause92.9
>>>>
>>>> Note I'm looking at draft 3.2 of the 802.3bj, and don't have the final
>>>> published version.
>>>>
>>>> George Zimmerman
>>>> Principal, CME Consulting
>>>> Experts in Advanced PHYsical Communications Technology
>>> george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx%3cmailto:george@xxxxxxxxxxxxxxxx>
>>>> microsoft.com<http://microsoft.com>>
>>>> 310-920-3860
>>>>
>>>> (PLEASE NOTE NEW EMAIL ADDRESS. THE OTHER WILL STILL WORK, BUT
>>> PLEASE
>>>> USE THIS FOR CME BUSINESS)
>>>>
>>>> From: Christopher T. Diminico [mailto:00000025925d7602-dmarc-
>>>> request@xxxxxxxx<mailto:request@xxxxxxxx>]
>>>> Sent: Wednesday, August 20, 2014 6:14 AM
>>>> To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3->
>>>> 25G@xxxxxxxxxxxxxxxxx<mailto:25G@xxxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder
>>>>
>>>> Colleagues,
>>>>
>>>> Based on the discussions of the objective given on slide 9 second
>>>> bullet in
>>> http://www.ieee802.org/3/25GSG/public/adhoc/architecture/nowell_08121
>>>> 4_25GE_adhoc.pdf
>>>> during the ad-hoc yesterday, I suggest we explicitly identify 802.3bj
>>>> channel by adding (TP0-TP5).
>>>>
>>>> Change from *Define a single-lane 25Gb/s PHY for operation over copper
>>>> twin-axial cables consistent with channels specified in
>>>> IEEEStd802.3bj-2014
>>>> Clause92 To *Define a single-lane 25Gb/s PHY for operation over copper
>>>> twin-axial cables consistent with channels (TP0-TP5) specified in
>>>> IEEEStd802.3bj-2014 Clause92
>>>>
>>>> Regards,
>>>>
>>>> Chris DiMinico
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Mark Nowell (mnowell)
>>>> <mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx%3cmailto:mnowell@xxxxxxxxx>>>
>>>> To: STDS-802-3-25G <STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-
>> <mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx%3cmailto:STDS-%0b>> 802-
>>>> 3-25G@xxxxxxxxxxxxxxxxx<mailto:3-25G@xxxxxxxxxxxxxxxxx>>>
>>>> Sent: Tue, Aug 19, 2014 6:17 pm
>>>> Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
>>>> Meeting Call for Presentation reminder Sorry everyone - calendar screw
>>>> up on my side around the re-arranged architecture ad-hoc meeting.
>>>> Will update soon with improved logistics.
>>>>
>>>> Mark
>>>>
>>>> On 8/19/14, 5:42 PM, "Mark Nowell (mnowell)"
>>>> <mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx%3cmailto:mnowell@xxxxxxxxx>>> wrote:
>>>>
>>>> Dear 25Gb/s Ethernet Study Group Members,
>>>>
>>>> A few reminders and updates:
>>>>
>>>> 1) Optical Ad-hoc is tomorrow Wed 8/20 @ 9am PST. Dial in details are
>>> here:
>>>> http://www.ieee802.org/3/25GSG/public/adhoc/index.html
>>>>
>>>> 2) Architecture ad-hoc meeting next week has moved to Wed 8/27 @ (am
>>>> PST (shifted from Tues). Dial in details are here:
>>>> http://www.ieee802.org/3/25GSG/public/adhoc/index.html
>>>>
>>>> 3) Reminders on Call for presentations and September Meeting planning.
>>>> Presentation request deadline is Friday Aug 29th. Please see my original
>>>> email for details on meeting logistics and travel planning (We meet
>>>> all-day Thurs and Friday).
>>>> http://www.ieee802.org/3/25GSG/email/msg00004.html
>>>>
>>>> As a reminder, the September Study Group meeting has limited meeting
>>>> time and the presentations will be focused on the Study Group work of
>>>> building objectives, developing responses to the CSD (5 Criteria) and PAR.
>>>> Presentations outside of the scope of those priorities will be given
>>>> time on agenda as possible.
>>>>
>>>> Regards...Mark