Re: [802.3_RTPGE] Preliminary Objectives -what are we missing - e.g., latency?

[Dave Estes <daestes@xxxxxxxxxxx>]

Hi,
I just want to point out that I was not expressing as opinion as to how many pairs should be listed in the objective.  I was simply pointing out that listing objectives relating to Clause 28 and Clause 33 would eliminate the possibility of using a single pair. 

Thanks,
Dave

On 6/27/2012 4:41 PM, Geoff Thompson wrote:

Yair-
There is no technical reason why power couldn't be delivered in an automotive environment with a single pair solution.  It certainly wouldn't be clause 33 but then it is not clear to me that clause 33 will be the right solution for this market anyway.

I think it is too early to limit our work to two pairs.  I believe that decision should be made be driven by the bandwidth/noise environment/reach requirements.

Geoff

On 276//12 8:54 AM, Darshan, Yair wrote:

Hi all,

 

Rephrasing Dave comment below, If the objectives is only one pair then clause 33 cannot be supported which I believe  is very limiting the scope of applications and the possibility to expand in the future to support clause 33.

I would suggest that the group initial objective may be to support two pairs, (data can be on one or two pairs) however the 2^nd pair will be available for power delivery per clause 33. We can always reduce to single pair  later if we will see that it cause issues.

 

Yair  

 

From: Dave Estes [mailto:daestes@xxxxxxxxxxx]
Sent: Tuesday, June 26, 2012 9:11 PM
To: STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_RTPGE] Preliminary Objectives -what are we missing - e.g., latency?

 

Hi George,
Including objectives for Clause 28 and Clause 33 (even optional) would restrict the Study Group to at least 2 twisted pairs.  If the study group is still considering only one pair we cannot include these objectives.

Thanks,
Dave

On 6/26/2012 1:02 PM, George Zimmerman wrote:

Seeing Brad’s note about the energy efficiency discussion reminded me that one of the reasons to consider not necessarily going directly with 802.3az at the face-to-face was that it would be desirable to use the network as a control network, and hence, packet latency would be an issue.

 

This got me thinking, should we have a latency objective?

 

Signal processing latency is probably not a PHY problem for normal modes, but could influence coding strategies for dealing with an impulsive EMC environment, and, would likely influence any transitions out of low-power states for energy efficiency.

 

It would be good to get the group’s minds thinking about what fundamental parameters we may have left out (of the kind that are specified in interface standards – e.g., not absolute power or complexity, but yes to reduced power modes, latency, speed, distance, media, duplexing, compatibility with environment & other signals, autonegotiation, etc.)

 

Here’s my list of what I think we’ve covered thus far:

Speed (fixed in the CFI – 1000Mb/s at MAC/PLS interface wording to be approved)

Media (fixed in the CFI – twisted pair copper, wording to be worked)

802.3 framing (agreed)

802.3 frame sizes (agreed)

Distance and/or channel loss, (still working the exact language)

Topology (3 connectors proposed, – to be approved)

EMC (still working the language)

BER performance (prelim agreed)

Training time from cold start (needs work and agreement, still)

Optional energy efficient operations (proposed – to be approved at this general level, may need further definition)

 

Questions on other issues that that have been raised, which, depending on the resolution, may be objectives:

Do we support clause 28 (or other) autonegotiation, even optionally?

Support or even compatibility with Clause 33 DTE Power over MDI (existing poe)?

Minimum latency (normal and especially for transitions out of low power mode)

 

-george

George Zimmerman

Principal, CME Consulting

Experts in Advanced PHYsical Communications Technology

Gzimmerman11@xxxxxxx

310-920-3860