Re: [802.3AZ] EEE - Negotiation clarification
Hi Hugh,
Thank you very much for your answers.
I have some doubts inline.
-Sujay
On Sat, Oct 4, 2008 at 12:14 AM, Hugh Barrass (hbarrass)
<hbarrass@xxxxxxxxx> wrote:
>
> Sujay,
>
> The first part of your question covers the PHY level Tq/Tr negotiation.
> The details of this are still being settled for each PHY type so you
> need to look at the definitions for the specific PHYs. The general
> principle is established that PHYs may be developed that require a
> relatively short refresh cycle (Tq > Tr) that reduces the energy when in
> the low power idle state. This meets the objective of the task force.
> However, it has been suggested that some PHYs may be able to support
> much longer refresh cycles (Tq >> Tr) and therefore save more energy.
> When two PHYs negotiate, if they both support the longer refresh cycle
> then it is clearly a good thing that they can both save more energy. If
> one of the PHYs needs a shorter refresh period then they must both use
> the shorter refresh period as that PHY will need to refresh its transmit
> and receive side circuits more frequently. This is the general
> principle, as the PHY details are settled the details will become clear.
SUJ>>
A long refresh cycle or a short refresh cycle for a given PHY host,
has to be essentially
maintained by its peer. ie. If Host A is on a short cycle , the peer
should send refresh signals
faster.
With this logic and assuming the Tx/Rx are separate circuitry, assume
A can support Long/Short Cycles
and B can only support Short Cycles. With A and B, I could well have a
scheme where A is running on
Long Cycle and B on Short Cycles.
So B would send refresh signals at a slow rate( as A is on Long Sleep
Cycle), and A would send refresh
earlier(as B is on Short Sleep Cycle).
Why wouldn't this work? Why do they both need to settle down to a
common Short Cycle?
> The second part of your question covers the system level wake up time. I
> think you have misunderstood the definition in the draft.
>
> Each host sends two numbers to its link partner (via LLDP).
>
> The transmit side wake time (transmit Tw) is the longest time that the
> host can wait after deasserting LPI, before sending data. This is
> typically governed by the transmit side buffering.
>
> The receive side wake time (receive Tw) is the receiver would like to
> use for the wake-up process. In other words it is the time that he
> receiver is requesting its link partner to wait after deasserting LPI
> before sending data.
>
> As you can see, this makes a total of 4 numbers exchanged. These numbers
> resolve to 2 resolved transmit wake times (resolved transmit Tw) - one
> for each host. For each host, its resolved transmit wake time is the
> smaller of its own transmit Tw and its link partner's receive Tw.
>
> Each host is now bound by its own resolved transmit Tw: it must wait for
> that amount of time after deasserting SPI before sending data.
> Additionally, each host will know how its link partner has resolved and
> so it will know how much wake-up time it will have between when the link
> partner deasserts LPI and when it can expect to receive data; it should
> choose its sleep mode accordingly.
>
> In your example
>
> A - Transmit Tw - 10 ms, Receive Tw - 20 ms B - Transmit Tw - 10 ms,
> Receive Tw - 20 ms
>
> (these cannot be the default value for the PHY type as the PHY has only
> 1 default Tw)
>
> Host A resolves (own transmit Tw = 10ms) vs (partner receive Tw = 20ms)
> - resolved transmit Tw = 10ms
>
>> SUJ
I did understand the flow, re-framing my question;
So if the resolved Tw is 10ms (as above) but the partner receive Tw is 20ms.
Does it mean that even though the peer( B) is requesting for A to hold for 20ms
A still holds for no more than 10 ms, and sends data much earlier to 20ms.
If it does, will it not cause loss of data(say B's circuitry, upper
layers are not up &
ready to receive data)?
Or do we have a plan in which even though B advertises Recv.Tw as
20ms, it is a best
case scenario and can be squeezed down to 10ms?(by the 'Tw-resolving'
method talked above)
> Host B resolves (own transmit Tw = 10ms) vs (partner receive Tw = 20ms)
> - resolved transmit Tw = 10ms
>
> Another,, more interesting example
>
> A - Transmit Tw - 20 ms, Receive Tw - 20 ms B - Transmit Tw - 10 ms,
> Receive Tw - 40 ms
>
> Host A resolves (own transmit Tw = 20ms) vs (partner receive Tw = 40ms)
> - resolved transmit Tw = 40ms
>
> Host B resolves (own transmit Tw = 10ms) vs (partner receive Tw = 20ms)
> - resolved transmit Tw = 10ms
>
> I hope that is clear.
>
> Hugh.
>
>
>
> -----Original Message-----
> From: sujay gupta [mailto:sujay.ietf@xxxxxxxxx]
> Sent: Friday, October 03, 2008 9:43 AM
> To: STDS-802-3-EEE@xxxxxxxxxxxxxxxxx
> Subject: [802.3AZ] EEE - Negotiation clarification
>
> Hi,
>
> I have a few doubt's when it comes to the Negotiation part as in the
> 802.3az 0.9 draft.
>
> Would be grateful for any clarifications provided.
>
>
> 1.) It is proposed that the systems exchange Tq/Tr supported in AN, and
> the lowest is settled for;
>
> For ex;
> A ------ B
>
> Tq/Tr(A) best case advertised is 'lowest energy' -> i.e. (Tq >> Tr)
> Tq/Tr(B) best case advertised is 'reduced energy' -> i.e. (Tq > Tr)
>
> And they both settle for Tq/Tr(B) , "to ensure lowest common value to
> ensure robust and quality link" .
>
> Now as the Tq/Tr parameters are useful only for the peer link partner,
> what is the benefit in making my peer choose a ratio which is not as
> energy efficient as what I may best support, just on the basis that my
> own Tq/Tr ratio cannot be as good as my peers.
> How does that effect "robustness" & "link quality"??
>
> In my opinion considering the asymettric nature of EEE ( ie only the TX
> triggers it not depending on the peer TX), it only effects the timers
> running on my side for the benefit of the peer. And gives an overall
> more efficient system rather than what would come by ensuring "lowest
> common value"
>
>
>
> 2.) In the LLDP negotiation, we resolve the Transmit Tw ( section
> 93.4.2.3 ) , to be the "minimum" of local Transmit Tw and the
> received(from the link partner) Receive Tw. And the local device shall
> wait for the time indicated by the Resolved time after deasserting from
> LPI and sending data packets.
>
> For ex:
>
> A - Transmit Tw - 10 ms, Receive Tw - 20 ms B - Transmit Tw - 10 ms,
> Receive Tw - 20 ms
>
> ( These values exchanged are default values for the given PHY)
>
> Now post LLDP exchange;
>
>
> On A;
> Resolved Tw, cannot be 10ms, as the peer Tw is at least 20ms, which is
> contrary to the statement of being minimum.
>
>
>
> Thanks,
>
> -Sujay
>