| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi all I have some comments to add to this
discussion. It is good to see that we are reaching an
agreement on the DS. I think now that we should look at how the
power is distributed and particularly the current sharing. First of all, we
agreed that any current sharing circuitry must be located in the PD. As mentioned previously, the high power PD
must be able to combine power coming from two different power sources (endspan
and midspan), so that a strong voltage difference between each (let’s say
5V) is possible. You could have one PSE output at 50V and
the other at 55V. In fact, each PD input could then have more than 6V
difference depending on cable length and PD power consumption. This means that any linear current sharing
mechanism in PD placed in front of its power supply stage will introduce
unacceptable power losses when the voltage difference is strong. Also, any passive current sharing
circuitry will not achieve any acceptable sharing of the current, unless the PD
current consumption is so low (probably less than 30W at PSE output) that no
sharing becomes really necessary, which case is considered irrelevant for this
discussion. Also, in the case where 2P are driven by
an endspan and the other 2P are driven from a midspan PSE, each PSE is interested
to know what power the PD needs on its 2P while it normally doesn’t care
about what happens on the other 2P. And each PSE need the PD to provide some
control on the 2P over which it provides power; this means the PD must control
its current consumption “per set of 2 pairs” and not simply on the
total 4P. The fact is that it is highly preferable
to come with a universal solution with no exception cases if at all possible.
It must be possible to connect 2P or 4P PDs with a combination of endspan-only
PSE or endspan-midspan PSE. And it must work for any PSE output voltage from
50V to the maximum allowable. Of course, some simple and minimal current
sharing at PD end without duplicating the power supply stage could result in
the cheapest solution of all, but it is realistically possible only if the
voltage difference between both power feed is limited, which can be the case
only if all 4P come from the same endspan PSE or at least are powered from the
same voltage source. On a system with endspan and midspan PSEs, it is most
probably not realistic and it becomes an exception case, which we want to
avoid, since the solution needs to be universal. The most universal 4P high power technique
involves a power supply with isolation per 2P, which means 2 power supplies for
4P. o
Each PD
2P then controls its own power consumption independently versus the other 2P. These
two power consumptions could be different depending on PD design. o
The
power supplies have either an independent load, or share the same load through
serial or parallel connexion o
At the
top-level system point of view, this is the simplest topology to manage and it
removes any exception cases. o
And it
works with endspan-only or midspan & endspan, since each PSE will know how
much power it will provide. o
This
removes any need for a 4P group code. A PD cannot simply indicate a total power
per group of 4 pairs and simply guarantee none of its 2P will not reach current
limit. o
This
technique also provides modularity, it is on a 2P basis. o
And this
is in line with the DS topology. However, I don’t mean we should
define that the only way is through the use of a power supply per 2P in the PD;
we should simply specify that the PD must be able to control and advertise its
power needs “per set of 2 pairs”, which is in line with a DS protocol.
Inevitably, in most cases, PD
manufacturers needing more than 25W will work on 4P and will simply duplicate
their basic 2P circuitry, using 2 power supplies. Regards Power Interface Systems Engineer Phone : 603-222-8683 jean_picard@xxxxxx From:
owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Steve Robbins 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. |