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

[8023-POEP] DS is the way to go.



Guys,

 

I’ve changed my mind.  I now fully support DS over SS.  Two reasons came to me over the weekend:

 

  1. I figured out a simple fix for one of my main concerns about the proposal that low-power PDs be SS, and high-power PDs be DS.  Instead of having a single power threshold to divide all PDs into these two types, we should have a grey zone.  The grey zone makes a big difference.  For example, we could put the following rules in the standard:

 

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.

 

  1. In Austin I said I couldn’t think of an application for what I called “case 6” where two separate PDs run off a single PSE port.  (I didn’t find the example of the security camera convincing.)  But now I think I’ve come up with the “killer app” for case 6.  The two PDs are an IP phone and desktop computer.  (See the presentation I gave in Vancouver about using PoE for standby power on desktop PCs)  With DS and L2, I think that app is now nearly perfect.  No need to go into further details on the reflector, but I think this app alone might justify the extra hardware costs associated with a DS PD (which was another of my concerns).

 

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 Yair Darshan
Sent: Sunday, May 28, 2006 3:49 AM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] DS vs. SS debate

 

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.

 

  1. We would like to have a standard that allows flexible implementation and note dictate specific ones that are relevant for today and may not be relevant tomorrow.
  2. Implementation can have high or low cost; it is a function of the requirements, the engineer experience and current vs future technology.

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.

  1. We know for a fact that:

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
Sent: Friday, May 26, 2006 8:15 PM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] DS vs. SS debate

 

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
Principal Engineer
Akros Silicon Inc.
(916) 351-8100 x-239
mike@xxxxxxxxxxxxxxxx
http://www.akrossilicon.com


From: owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of Steve Robbins
Sent: Thursday, May 25, 2006 5:51 PM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] DS vs. SS debate

 

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:

 

  1. Suppose we go with DS.  Then we’re faced with the signature-ambiguity issue I covered in Austin.  Depending on the setup, a DS PSE might see two class signatures or only one.  How do we make it so that the correct info is tranfered in all cases?

 

  1. I got the impression in Austin that the favored solution to this problem is to have two types of PD.  Low to medium power PDs would use SS, and high-power PDs would use DS.  This avoids ambiguity by keeping both 2P halves of a 4P system completely separate, so that each PSE only sees one class signature in all cases.

 

  1. If we go with this approach then the standard would have to define a specific power threshold (let’s call it P).  Any PD that draws power <P must be SS, and any PD drawing >=P must be DS.  Then the issue becomes, how do we choose P?

 

    1. If we want users to be able to combine Af-endspans with At-midspans to power a PD up to 26W, then obviously, P=13W.  But then there would be no such thing as medium power on 2P.

 

    1. If we set P=25W for example, we satisfy the desire for 2P medium power, but then any PD in the 13W to 25W range can’t be powered by combining Af-endspan with Af-midspan.  So we’d be ruling out one of the supposed advantages of the DS architecture.

 

  1. Suppose we set P=13W to allow people to get the most reuse out of their legacy Af hardware.  Then we’ve created a real problem for PD designers by forcing them to pick either SS or DS.  If they pick wrong, they will have to do a serious respin of their board.  Any PD designer who thinks he’s close to the line will have to play it safe and choose DS.  But a DS PD must request at least 13W (otherwise it should be SS).  So there will likely be a lot of PDs that request 13W just because they’re DS, when they really only need say 8W, but the designer didn’t want to risk making it SS.  In other words, there would be a serious incentive to waste power in order to avoid risk.

 

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:

 

  1. Remember that power management is more than simply allocating Watts from a PSEs power budget.  Power management also includes things like a GUI where users can turn loads on or off, set priorities, etc.

 

  1. How would the GUI look in a DS system?  Right now, if two PSEs were powering a DS PD, then the user would have to deal with two separate GUIs, perhaps from different vendors.

 

  1. Ideally, third-party software solutions would emerge.  (In fact, we should encourage them since that would help expand the PoE market.)  But how could anyone develop software that combines two separate PSEs into a single “virtual” PSE with a single GUI?  At a minimum this would require:

 

    1. Standardization of the command line syntax.  (Not very likely in my opinion.)

 

    1. Some way for the system to map which PSE ports are associated with which PDs.  For example, how would the software know that a particular DS PD is connected to port 1 on the endspan and port 7 on the midspan?  Either the user would have to enter the mapping info manually, or the midspans would have to include PHY chips.

 

 

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
Sent: Thursday, May 25, 2006 1:31 PM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] DS vs. SS debate

 

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
Sent: Thursday, May 25, 2006 2:12 PM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] DS vs. SS debate

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 Steve Robbins
Sent: Thursday, May 25, 2006 10:26 AM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: [8023-POEP] DS vs. SS debate

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 Austin meeting, so the DS vs. SS debate must go on.

 

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.