| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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] 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] Hi George,
-- Michael J. Bennett Energy Sciences Network Lawrence Berkeley National Laboratory (510) 486-7913 |