| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Guys, I’ve changed my mind. I now
fully support DS over SS. Two reasons came to me over the weekend:
RULE 1: All PDs
that require less than 13W shall be SS. RULE 2: All PDs
that require more than 30W shall be DS. (The 30W number is tentative of
course) RULE 3: All PDs in
the range of 13W to 30W may be either SS or DS. (This is the grey zone.) RULE 4: All SS PDs
shall request 100% of their power needs on their single classification
signature. RULE 5: All DS PDs
shall request 50% of their power needs on each of their two classification
signatures. Rule 1 is necessary to
meet objectives 13 and 14 which state low-power At-PDs should be interoperable
with Af-PSEs. Rule 2 is necessary to
prevent overheating the cables. Power > TBD (30W in this example) must
be on 4P. Rule 3 does two
things. It allows for medium power on 2P, and also greatly reduces the
risk that a PD designer might make the wrong choice between DS and SS, and consequently
have to re-spin the board. (Thus eliminating a big incentive for PD
designers to waste power budget by choosing DS when they should choose SS.) Rules 4 and 5 eliminate class
ambiguity.
So now I’m sold. I’m
still concerned over some potential software issues, but overall I’m sure
DS is the way to go. Steve From: owner-stds-802-3-poep@xxxxxxxx
[mailto:owner-stds-802-3-poep@xxxxxxxx] On
Behalf Of Hi all, As one already said we can argue on this
forever. There is a way to simplify the discussion. The way that I am proposing is to review the
cost effectiveness of DS vs SS from PDs market point of view. Let's see the facts again.
Since we don’t have
control on none of the above, we should allow a specification that maintain
interoperability, reliability and clarity and is transparent to application and
implementation.
a) PDs may need to combine power from two different power sources. We know
for a fact that currently these two sources are within the same communication
room. Can be
Ends span +Mispan or 2X2ports in endspan or 2x2ports in Midspan. b) Some companies consider building 2P MP switches and if PD wants
more he can take the rest of the power from a Midspan. c) There is a strong requirement to operate the same PD with totally
different loads. d) Classification is the mean which we use to distinguish between
802.3af and 802.3at since we don’t want to change the resistor signature
requirements and algorithm. Taking
all the above shows that adding additional class signature that adds only
<0.3% to the total PD cost is a small price to pay for simpler standard,
additional degree of freedom in term of accurate PD type detection in addition
to the fact that signature detection is required for any two pairs any way
according to 802.3af specifications. Using SS
only adds more confusion to the detected class value since it is not supplying
the whole data required on the PD for efficient power management. The
other questions such as reliability etc. are less important compared to questions
such simple standard or not? Enough data on PD or not? Supply market needs or
not? Reliability
can be addressed later in the implementation level. Yair From:
owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Michael Altmann Steve, I think many of your points contain their
own answers. It’s pretty clear, from your discussion in #3 &
#4, that #2 adds needless complexity (why create yet another threshold that
needs to be verified?), and doesn’t solve anything. In effect this
creates a single signature (just presented on two lines). It also
illustrates the trouble we will have trying make any SS scheme work. Any attempt to combine two signatures,
which could require equal or unequal power, into a single effective signature
causes larger system-wide complexity. The example you use below is that
26W would be split 13/13, however a single signature does not work if the power
requirements are more optimally split unequally in the PD, for example 6/20. A
DS scheme would manage this very simply. Discussion of more complex power
management (i.e. some form of client-aware power control) requires L2, as there
is no identifying of devices (and their valid power levels) through our L1
classification scheme, so I would conclude that this is immaterial to our
L1-classification discussion. While the control GUI is a neat idea,
I’m not clear how the PSE control discussion supports SS. The
problem is the power distribution, not the signature. Very simply, DS
enables separately-power pairs at the PD, while SS does not. Since this
has been discussed as a valid power-upgrade path for systems, we should support
it. From this, it seems to me that the only
problem to be solved with DS is how to make the PD present a well-controlled
classification on each 2P combinations. Since this only applies to .af
PDs, is this really a problem? …/Mike Michael Altmann From: owner-stds-802-3-poep@xxxxxxxx
[mailto:owner-stds-802-3-poep@xxxxxxxx] On
Behalf Of Dan and Matt, Thanks for replying. I was really
just asking how we should proceed. I don’t think we can reach any
answers over the reflector, but I guess some discussion on the reflector is
probably a good thing. In regard to Matts statement that simpler
is better, I couldn’t agree more. It’s just that I
don’t believe DS is as simple as Hugh seems to think it is. For
example, look at this chain of reasoning:
I know that there are plenty of
alternative branches to this chain of logic, and some people would probably
dispute the whole thing. But it illustrates my point that DS is not
necessarily a nice simple solution. Also, let’s not forget the software
aspect of this whole thing. Here is another example:
For a strictly SS architecture you
don’t get any of these problems, although you do get other
problems. The whole point of this is that you can’t say DS is
simpler than SS. We have to take a serious look at all the consequences
before we decide, and I think we’ve only just scratched the surface. Steve From:
owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Matthew Landry Dan, I agree with your thinking.
Most powered devices will be 2PMP, and hence ignorant of 4P issues. But,
you conclude that the easiest solution is to define a Single Signature for a 4P
PD, while it seems to me that the Dual Signature is truly the easiest solution
in terms of writing the standard and achieving well-defined system interaction. Those powered devices that want to capture
4PHP can decide how they want to present their independent signatures on the
pairs (concurrently, sequentially, whatever), as well as how to combine the
power that they will be receiving from any of a number of mixed sources (viz.
the various cases identified by Yair and Steve). We all agree that there are additional
burdens concomitant with 4PHP -- the most significant of which is probably
combining the possibly disparate power sources. That PD cost -- be it
silicon cost or implementation headache cost -- towers over the cost of
providing two independent signatures. Couple that with the questionable
value of the PSE knowing whether it is talking to two 2P PDs or one 4P PD and
the added complexity of writing it into the standard, the 4P Single Signature
approach is a hard sell. As Hugh expounded so thoroughly, simpler
is better. Now, the question is: can we agree on which method is simpler? I believe that since the meeting is over,
we don't have any ability to change the purpose of the classification ad hoc --
but that doesn't mean that Clay can't choose to give over the teleconference
time to DS/SS discussion. The reflector might also be an acceptable forum
for hammering out this issue. Cheers, Matt From:
owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Dove, Dan Steve, Perhaps I am being too simplistic, but it
seems like we should have SS and be done with it. I think that case 6 is
unnecessary and case 5 can be dealt with in the PD if they want to take power
from all 4 pairs, but that would be the high power case and I don't think we
should burden the spec with implementation challenges of high power. I
anticipate the vast market demand is going to be two-pair medium-low power
applications and therefore would try to optimize for that market space. I appreciate your suggestion to try to get
concensus prior to the next meeting and if you want to put up a "SS
proposal" I would likely support it. Dan ------------ Previous Message Below ------------ From:
owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Guys, This email is intended for people who are interested in the
DS vs. SS debate, or the classification adhoc. If you’re not one of
those people then please disregard this. Unfortunately, no decision was reached in the This issue is far too important to just let it sit until the
plenary. We must have it all figured out before the plenary, otherwise we
probably won’t reach a decision then either. And, as we all know,
the 802.3at Task Force is already way behind schedule. My question is, how should we proceed from here? So
far, the discussion forum has been the classification adhoc, but this is really
outside their scope. Should the Task Force start a new adhoc, or morph
the classification adhoc into a system architecture adhoc? I think we need to make a decision quickly, and continue the
debate aggressively. Steve Ignore this legal statement: This
email and any attachments thereto may contain private, confidential, and
privileged material for the sole use of the intended recipient. Any review,
copying, or distribution of this email (or any attachments thereto) by others
is strictly prohibited. If you are not the intended recipient, please contact
the sender immediately and permanently delete the original and any copies of
this email and any attachments thereto. |