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

Re: [STDS-802-3-25G] 25G CR objective wording



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