| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dave, Geoff, I agree that power wise, there is no technical issues to work
with single pair and decision should be driven by bandwidth/noise
environment/reach requirements. Yair From: Dave Dwelley
[mailto:ddwelley1@xxxxxxxxx] Yair,
Geoff - Agreed -
there are non-clause-33 solutions that can work with a single pair. This is
certainly a topic for discussion in San Diego, but I don't see a need to limit
us to two pairs right now. Note that a single-pair DSL-style scheme affects the
coupling passives but not necessarily the PoE silicon - hypothetically, if we
were to define a single pair DSL-style scheme using 55VDC and 25k, customers
could use existing PoE chips. Dave ----- Forwarded Message ----- Yair- 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 2nd 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] Hi
George, 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 310-920-3860 |