| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Chad,
I have a few of comments on your presentation:
1. I understand your approach. You want to use as many of the new codes above 15.4W as possible, but you have to use one of them for 2W because the task force mandated we go down to 2W. I guess that's a reasonable approach except for two concerns:
a. Your max power level is only 30W. I don't
think that's future-proof enough.
[[cmjones]] 30
is only an example. I gave the equation on the following
page.
b.
There is still that huge gap in between 7W and
15.4W. For example, a PD that needs 8W must still request 15.4W, thus wasting 7.4W, or 48% of the allocated
power. I think a lot of PDs might fall in this gap, and I'm pretty
sure we need at least one new code in there.
[[cmjones]] AF
is what it is, it can't change. For the same reasons I opposed the 2W
class, I oppose any new classes below 15.4W. this is just my
opinion and you have the right to disagree. In the end, the standards
process will result in the group
will.
2. I
don't like the fact that a "31" code requests only 2W. An AF-PSE will only
see the "3" and will allocate 15.4W when the PD is only requesting
2W. That's
extremely wasteful. Why not use "13" instead? Then an AF-PSE would allocate only
4W.
[[cmjones]] I will explain this in more detail tomorrow,
but the concern is AT PSEs with AF
PDs.
step 1: AT PSE applies first ping pong finger.
step 2: AF PD presents first class.
step 3: AT PSE see first class and sends the trigger to change states. I recommend going above class voltage, I have heard from others that below class voltage may be problematic.
step 4: here is where it gets trick. since AF was never intended to go above class voltage and back into class voltage, the PD behavior is undefined. If the PD is well behaved it shows the same class again. Everything is fine, the AT PSE provides the proper power level. If the PD draws an unexpected current in the other class ranges, it gets falsely discovered as an AT PD, the AT PSE powers it up and provides LESS POWER THAN REQUIRED.
3. The "44"
code is basically wasted. Any code that starts with a 4 will be
interpreted by
and AF-PSE as Class 0, and it will allocate 15.4W. So
there's no
reason to define both 33
and
44 as 15.4W. You should use it for some other power level, like you did
with 41, 42, and 43.
[[cmjones]] for the same reasons that "11", "22",
and "33" cannot be used, "44" cannot be defined anything but 15.4W.
AF already dictates that a PSE that detects a class 4 PD treats it as class
0. So I am not defining it as 15.4W, I am stating that it is already
defined as 15.4W.
4.
You don't say what we should do with the other 6 codes that aren't in your table. If we leave them undefined, then
someone will try to use them for proprietary purposes.
[[cmjones]] agreed. of course we would define all the
possibilities and label the prohibited. Undefined or reserved
will also end up in proprietary
solutions.
I don't understand your comment about "false detection of legacy PDs" using the codes I proposed. I can't see the problem, but I guess we'll discuss it tomorrow. Thanks to taking the time to read my proposal at least.
Steve
-----Original
Message-----
From: owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx]
On Behalf Of Clay Stanford (LTC)
Sent: Tuesday, June 13, 2006 3:43 PM
To:
STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: [8023-POEP] 2-Finger Ping Pong
Presentation
Attached is a presentation from Chad for the group.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around