Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi George, I believe that you are referring to my latest proposal to Lennart (on June 13) to a shorter text i.e. : "IPort_MPS may be affected by Irev. See 145.2.10.4, 145.3.8.8.” which you also suggested to Chad. All my emails for the last 3 days where about this text and not the previous longer
one. I believe that the probability for this text to create new comments is low. And if I am wrong, let’s take this text and remove or change the things that you believe are problematic. Addressing your inputs: -why using “may” is a problem in informative text? -The question if using affect or effect looks to me trivial since the text says “…may be affected..” which looks to me as a correct form when “affected” is used. Am I missing anything
here? What about: "Irev may change the value of IPort_MPS. See 145.2.10.4, 145.3.8.8.” (so one less concern) Regarding “may”, still I don’t see the problem? Yair
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
EXTERNAL EMAIL FYI – I had suggested this to Chad because the text as proposed would likely have generated another round of comments (due to the use of may, and common confusion with “affect” vs.
“effect”). This is the kind of thing that happens when you change text at the last minute without actually adding a technical specification. I want to make it clear – I still oppose the change, which is purely informative and doesn’t change the technical
requirements. I did not send the suggestion to the reflector because I did not want (and do not want) to help fix a broken car and therefore put my fingerprints on it, only to later find it involved
in a hit-and-run accident… George A. Zimmerman, Ph.D. President & Principal Consultant CME Consulting, Inc. Experts in PHYsical Layer Communications 1-310-920-3860 From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Which I am OK with this solution. Yair From: Chad Jones (cmjones) [mailto:00000b60b3f54e8d-dmarc-request@xxxxxxxx]
EXTERNAL EMAIL Editorial suggestions have been sent to me offline. Here is the recommended text to consider as the solution: IPort_MPS can be impacted by Irev. See 145.2.10.4, 145.3.8.8. Chad Jones Tech Lead, Cisco Systems Chair, IEEE P802.3bt 4PPoE Task Force Principal, NFPA 70 CMP3 From:
George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> George A. Zimmerman, Ph.D. President & Principal Consultant CME Consulting, Inc. Experts in PHYsical Layer Communications 1-310-920-3860 From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Hi Chris, All what you said is true but it is not easy to understand the effect of Irev on PD. See how much work I and others invested to investigate the potential issues, we have found issues and as a result we change the proposed
baseline until we clear all issues. We did it for every function. We didn’t do it for MPS. Now I am trying to complete my work and address this item
to. As I said in my previous mails: This is the first time that setting a PD parameter is depend on other PSE parameter in a very complex
scenario: PSE is a 4-pair but operate in 2-pair that is actually 3-pair and is connected to a PD that uses ideal diode bridge that if it gets 3-pairs
due to design mistake (that many of us did..) is backffeding and as a result anything that exists at the PSE unpowered pair is reflected and became part of the PD signature, PD class (new news: PD MPS) which may alter its performance.
Now, how a PD designer will understand all of this in fair amount of time without being part of our group or without given a hint to look
for this dependencies? The key issue is: we had never had a parameter specified in the PD that is affected by a parameter in the PSE. Please check and verify
that until D3.4 all PD initial parameters where set only by the PD and PSE has zero control on it. D3.5 violates this concept and we need to make sure that we are not misleading the reader. Yair
From: Chris Bullock (bullock) [mailto:bullock@xxxxxxxxx]
EXTERNAL EMAIL Hi Yair, In clause 33, we did not mention Ihold in the PD section. If the PD designer wanted to implement the feature
that you are talking about, he would have had to read the PSE section to understand the Ihold thresholds and timing. The same is true in 802.3bt, except now the PD designer needs to read the PSE section to understand Ihold and Irev. This is nothing new. Thanks, Chris From: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Hi Chris, Not sure that I understand the question. In clause 33, we are working on 2-pair. When working over 2-pair, you need to meet backffed at any voltage (detection , classification
powerup/on) which means maximum 2.8V over 100K i.e. maximum 28uA. This means that nothing is reflected from the unpowered pair to the signature resistor, classification current or MPS. So, we don’t
have problem and PD set its MPS current per the PD needs without the concern that something in the PSE will affect the MPS current. In 802.3bt D3.5 in a 4-pair system, when we operate in 2-pair (which is 3-pair), we need to address the case of the PDs with the ideal
diode bridge that doesn’t meet backfeed in 3-pair. This behavior cause to any impedance on the PSE on the unpowered pair to be reflected in parallel
to the PD elements and cause that to change their total value which ends up with change of resistance or current at the PD. In our case it is the MPS. The MPS current is affected by Irev which is generated in the PSE on the unpowered pair. So, a PD is set its
MPS in order to be disconnected but due to Irev in the PSE, the PD MPS setting will be changed and present a new value that may end with keep the PD powered which was not the intent of the PD!
Now in order to not mislead the PD designer, in case he is not aware of Irev because Irev is not in the PD spec, I suggest to tell the
PD that he need to be aware of Irev when he sets the value of the PD MPS in order to achieve the PD goals. Yair From: Chris Bullock (bullock) [mailto:bullock@xxxxxxxxx]
EXTERNAL EMAIL Hi Yair, In clause 33, we did not tell the PD designer about Ihold. Why is this different? Thanks, Chris From: Yair Darshan <YDarshan@xxxxxxxxxxxxx>
Hi George, I am not necessarily suggesting new values or more informative information etc. This is not my intention. You are welcome to offer simpler
text. I can’t agree to leave this
as is. Again, the problem is: If PD vendors don’t read
PSE section, how they can be aware of Irev in 3-pair mode which is in the PSE section and affect the MPS on the PD section? Before we wavered on backffed requirements in 3-pair mode i.e. backfeed was required to be met and all PSE voltage range, we had never
this situation before that meeting the PD spec depends on PSE spec. This situation will be a source of interoperability issues and I am trying to resolve it at ZERO cost/issues for the ideal diode bridges in the field (instead of asking again to disallow new
Type 3 and 4 PDs from having backfeed issues in power on state). Without adding some hint/link/text to the PSE Irev in PD MPS clause, we will mislead the PD designer.
Please note that my proposed approach was the normal approach we took in similar cases. This is no different than the other cases. Yair From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
EXTERNAL EMAIL Yair – all of these values are tutorial in nature. There are no requirements in your proposed text, therefore they are completely advisory. We write standards – the important thing to capture is what is required. The information may be valuable to implementers, I don’t argue
that. However, publish that elsewhere (for example, in an EA whitepaper) if you so desire. George A. Zimmerman, Ph.D. President & Principal Consultant CME Consulting, Inc. Experts in PHYsical Layer Communications 1-310-920-3860 From: Yair Darshan [mailto:YDarshan@xxxxxxxxxxxxx]
Hi George, The value of the proposed text is much higher that you have described see why: The issue is: -PD operates in 3-pair mode with ideal diode bridge that has the backfeed issue. This means that whatever load is in the unpowered PSE
alternative, it is reflected to the PD load and added up. -PD wants to be powered off. As a result it sets its MPS to 3.9mA which means must be OFF. PD vendor may not be aware of the Irev spec
since it is in the PSE spec. -Now in this condition Irev=1.3mA will be added from the PSE to the PD MPS i.e. 3.9mA+1.3mA=5.2mA and PD will not be disconnected. This is the problem. The solution is that the PD vendor will take the 1.3mA in account of the MPS setting. The problem is that the PD vendor is not aware of Irev since this is the PSE spec and many times as a response to comment we agree to
add text to PD section to tell PD about parameters that affects the PD but appear in the PSE i.e. we said that the PD vendor get a PD spec and start to design without looking on PSE spec or aware of it which I believe it is a correct scenario. By the way, during last meeting we change the PSE and PD spec to address similar issues concerning to the effect of Irev on other spec
items and this is one of them. I can never agree to a situation that you have a clear requirement in a PD for what to do regarding MPS (or other spec items) without
telling the PD vendor that there is something waiting for him in the corner… in the PSE spec that is not mentioned in the PD spec that can make his
PD uncompliant. I don’t see a reason to hide such critical information. Yair From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
EXTERNAL EMAIL
Yair - the proposed text is purely advisory and informative. At this stage we should only be concerned with missing or incorrect requirements or correcting (preferably deleting) incorrect information. I just don’t
see the point of adding more informative advice to the standard. George A. Zimmerman, Ph.D. CME Consulting, Inc. Experts in PHYsical Layer Communications 310-920-3860
Hi Lennart, I agree that it doesn’t affect
the case when the PD is disconnected from the cable. I was referring to the case that the PD is connected and wants power removal. The question if it is rare or not, is irrelevant since it
is already in the spec and we need to address it somehow and meet it. I agree that the solution can be that PDs that do want to have power removed can set their Iport_mps value for power removal to be lower
than (4mA-1.3mA)=2.7mA. However, in order to make this clear to the PD vendor (since Irev is in the PSE section) I believe that we need to add text to the PD MPS section as follows (or equivalent): Proposed remedy: Add the following text in clause 145.3.9, page 222 text after line 49: "When a PD is operating under 3-pair mode conditions, the value of IPort_MPS as seen by the PSE over the powered pair may increase by
Irev (See 145.2.10.4, 145.3.8.8 ). As a result, the PD may need to set IPort_MPS to alower value than IPort_MPS min to ensure power removal." Yair From: Lennart Yseboodt [mailto:00000b30a2081bcd-dmarc-request@xxxxxxxx]
EXTERNAL EMAIL Hi Yair, Your analysis is correct, the reverse current is added to the PDs own current. I don't consider this an issue we need to do anything about however: - it does not impair the primary function of MPS in any way (to remove power when the PD is disconnected) - it only affects PDs that use the method of removing MPS in order to have the PSE remove power, I would say this is pretty rare; - PDs that do want to have power removed can accommodate for the maximum 1.3mA of reverse current (draw less than 2.7mA of their own) Note that reverse current only happens under 3-pair conditions, and then the 'must disconnect' current level is 4mA for PSEs. Kind regards, Lennart On Mon, 2018-06-11 at 12:03 +0000, Yair Darshan wrote:
To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1
To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1
To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1
To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1
To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1
To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1
To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 To unsubscribe from the STDS-802-3-4PPOE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 To unsubscribe from the STDS-802-3-4PPOE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-4PPOE&A=1 |