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

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



The PHYs in 802.3 are specified with round-trip time (RTT). Usually this is done as an estimate of what the upper bound could be and is added to the specification during the task force phase of a project.

 

For this effort, it may be helpful to understand if there is an upper bound RTT that needs to be considered. It may not require an objective, but that would be for the study group to decide. Does anyone have data on this relative to the automotive or industrial markets?

 

On another note, I believe there should be consideration for an auto-negotiation objective. While this may not be a requirement in the automotive market due how systems are implemented, but outside of that market, it is going to be extremely useful. I believe that’s the point Joseph was trying to make on the conference call.

 

Cheers,

Brad

 

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, June 26, 2012 1:10 PM
To: STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_RTPGE] Preliminary Objectives -what are we missing - e.g., latency?

 

George,

 

Perhaps I did hyper-interpreted what was posted before. The point that I was trying to make (and failed, apparently) was that setting a tight goal right now (say, 100 ns) might impair progress of the group if it is found that due to EM requirements, it cannot be met. Then the only way forward would be to have objectives changed, which is always an administrative hurdle to go through. I’d very much rather see TF execute common sense in designing the PHY and minimizing latency subject to EM and channel model considerations than promise right now something that may not be achieved, if it is found later on to be too aggressive. In a nutshell, I’d think that putting more than “minimize latency” objective might be asking for trouble, unless SG has seen already presentations to this end and can easily agree on what number would be good enough.

 

From past experience, not all PHY parameters have to be covered in objectives, especially if the plant conditions are unknown and the channel model does not yet exist. It is fine to specify them later on, as long as common sense approach is adopted and latency is minimized.

 

Marek

 

From: George Zimmerman [mailto:gzimmerman11@xxxxxxx]
Sent: 26 June 2012 18:54
To: STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_RTPGE] Preliminary Objectives -what are we missing - e.g., latency?

 

Marek –

This may be a requirement that directly effects the directions we take in the standard, and I think, perhaps you misunderstand me.  I am very much for vendor differentiation, and am neither looking for overly tight objectives (e.g., 100nsec), but rather, understanding how they are relative to say 1000BASE-T.  I would think that because of the environment and energy efficiency desires the latency would be larger than 1000BASE-T (bigger than, for example, 84 + 244 bit times, or 328nsec, for TX_EN to get to the receiver, excluding prop delay).  The MAC/PAUSE control limit isn’t too much bigger, with a pause quantum, 512 bit times, being 0.512 microseconds.

 

In the end, I believe that latency will get specified, as it does in all IEEE PHYs, but, the question remains whether it is loose enough that it is a “don’t care” for the objectives.

 

Thomas Hogemuller’s presentation (http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hogenmuller_01_0512.pdf) discussed drivers assistance cases, which I wouldn’t expect to be microsecond latencies, but might be hundreds of microseconds or single-digit milliseconds.  I recall, but couldn’t find, someone mentioning engine management.  If we get machine-to-machine control going on these networks it is really short. 

 

As I know Mike and Brad are aware, but others may not be, one path to energy efficiency (particularly in .3az) comes from being able to hold up and gather traffic.  This will happen in any system that I can envision which provides for reduced power modes (because reduced power modes necessarily reduce the links’ performance, otherwise they would just be normal operation at a lower power, and not a mode at all).

 

Because of the EMC environment, I’m inclined to think latency will be a key parameter, and will be greater than 1000BASE-T.  The question for our friends in the automotive space is, how much do you think is too much for your applications?  - if it isn’t too tight, e.g., hundreds of microseconds, it probably isn’t an issue requiring an objective.  If it is, however, tens or single-digit microseconds, then we may need it worded into the energy efficiency objective, and possibly as its own objective, as it might have wider impacts.

 

I would agree with Marek, however, that requirements under a microsecond will have substantial impact on complexity.  I really just wanted to put the request out there for the users to weigh in.

-george

 

From: Mike Bennett [mailto:mjb@xxxxxx]
Sent: Tuesday, June 26, 2012 10:09 AM
To: George Zimmerman
Cc: STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_RTPGE] Preliminary Objectives -what are we missing - e.g., latency?

 

Hi George,

It would be useful to know what the latency boundaries for the energy-efficient operations work.  I don't know if an objective is required for that, but it a necessary discussion to be had.

Mike

On 6/26/12 10:02 AM, 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

 



-- 
Michael J. Bennett
Energy Sciences Network
Lawrence Berkeley National Laboratory
(510) 486-7913