Thread Links  Date Links  

Thread Prev  Thread Next  Thread Index  Date Prev  Date Next  Date Index 
Hi Heath,
IPeak2P indeed depends on Rchan, in 2 ways. First in Eq 3310, IPeak depends on Rchan. Second, KIPeak in Eq 3312 also depends on Rchan.
Because this is so complex (and useless to optimize for), a 'simple' worstcase calculation is provided in the form of IPeak2Punb_max. This number is higher than IPeak2Punb and using this would automatically mean meeting peak unbalance requirements.
With regard to George's comment that the lowerbound template should not depend on Rchan... that has always been the case, since at least AT. ICon also depends on Rchan for instance. Here it does make sense as it allows a PSE to optimize the power output to match with the channel losses.
Kind regards,
Lennart From: Heath Stewart <00000855853231d4dmarcrequest@xxxxxxxx>
Sent: Friday, January 6, 2017 0:13 To: STDS80234PPOE@xxxxxxxxxxxxxxxxx Subject: Re: [802.3_4PPOE] Rewrite of 33.2.8.5 All,
We are noticing a few incongruities after looking at this longer.
1) Inadvertent change
"Alternatively, an overmargined value of IPeak2Punb, IPeak2Punb_max which is defined by Equation (33–14), may be used."
is incorrect. It creates an alternate definition of IPeak2Punb.
It used to create a new variable, IPeak2Punb_max, which happens to have a relationship to IPeak2Punb. We need to preserve the original wording. This term is only used to form Iunb.
"The worst case value of IPeak2Punb is IPeak2Punb_max which is defined by Equation (33–14)." 2) The lowerbound template as defined by IPeak2P (by way of IPeak2P_unb) now has a third dimension, Rchan2P. This is not only strange but is at odds with the definition of Icon2P_unb, which is a scalar.
Is this what we want?
Cheers,
Heath
On Wed, Jan 4, 2017 at 1:30 PM, Abramson, David
<david.abramson@xxxxxx> wrote:
