By: Andrei F (andrei.delete@this.anandtech.com), September 17, 2021 1:35 am
Room: Moderated Discussions
David Kanter (dkanter.delete@this.realworldtech.com) on September 16, 2021 12:04 pm wrote:
> Andrei F (andrei.delete@this.anandtech.com) on September 16, 2021 8:12 am wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on September 15, 2021 11:46 am wrote:
> > > > > Isn't the point to deliver max perf with min energy?
> > > >
> > > > The point is that your window of user experience is 16/8ms. If the workload completes
> > > > interactively to fill that "QoS" at the current frequency without going over a utilisation
> > > > threshold in that sliding window, you *do not want to go any higher*.
> > >
> > >
> > > Wouldn't you want to run at lower voltage/frequency if possible?
> >
> > My point is you're already running at the lowest frequency without failing to deliver the QoS/frame.
> > If the performance window is smaller, then you'd be running at higher frequencies to service the
> > higher load periods, and low frequencies during lower load periods, which costs more energy than
> > running medium frequency the whole time and spreading out the load over the frame.
>
> My point is that even within 10ms, the optimal voltage will
> probably vary quite a bit (assuming fixed frequency).
Are you alluding to vdroop? This is a completely different discussion. The margins for efficiency gains are an order of magnitude lower than actual V/F switching.
>
> > >
> > > Generally the point is changing V/F should be inexpensive to enable using the optimal V/F combo.
> > >
> > > > So your 120MHz FIVR is completely and utterly pointless. You would be wasting energy at higher
> > > > voltages for no gain in user performance.
> > >
> > > Shifting to low voltage fast seems valuable, right?
> >
> > It doesn't because of the above reasons. You should be running
> > at the "just right" F/V servicing the workload.
>
> Let's say you are running at 2GHz. 8ms is 16M cycles. The 'best' voltage will
> vary over those 16M cycles based on activity in the chip, temperature, etc.
We already have these mechanisms in products right now / vdroop / temperature DVS. Yes you can have DVS that goes infinitely fast and does envelope tracking to the load. But that's a layer that sits underneath the DVFS logic.
>
> > > > Fmax should only every be reached and triggered after
> > > > continuous load of 2-3x of user experience window - current mobile phones do that in around 40-50ms,
> > > > anything faster than that is waste of energy and battery life. These are not HW limitations, but
> > > > learning the hard way what the most efficient way to design battery powered DVFS logic.
> > >
> > > Would that change if V/F switch took nanoseconds and cost little energy?
> > >
> > > Seems like you would want to dynamically adjust voltage...even if at fixed frequency.
> > >
> > > David
> >
> > If it would take nanoseconds to change V/F then all you're doing is having two states - Fmax and Fmin.
> > A that point Fmin becomes meaningless as a state and it's better to just clock gate/power gate. Your
> > most prevalent state in which you do computation would be Fmax and you defeat the purpose of DVFS.
>
> Well voltage can change quite rapidly. I think Intel's FIVR is around 1V
> in 0.5us. So if you wanted to change 50mV, that's probably quite quick.
>
> David
Again, I agree, but it's a different discussion topic. Currently vendors can't even rationalise dedicated voltage rails much less something like a FIVR - Qualcomm notes they use 1+3 on the same voltage rail because the increased capacitance of the larger rail brings more benefits than a dedicated rail. 50mV is an extremely excessive swing at constant frequency, but I guess it could happen on very high power cores, but that's a different market segment.
> Andrei F (andrei.delete@this.anandtech.com) on September 16, 2021 8:12 am wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on September 15, 2021 11:46 am wrote:
> > > > > Isn't the point to deliver max perf with min energy?
> > > >
> > > > The point is that your window of user experience is 16/8ms. If the workload completes
> > > > interactively to fill that "QoS" at the current frequency without going over a utilisation
> > > > threshold in that sliding window, you *do not want to go any higher*.
> > >
> > >
> > > Wouldn't you want to run at lower voltage/frequency if possible?
> >
> > My point is you're already running at the lowest frequency without failing to deliver the QoS/frame.
> > If the performance window is smaller, then you'd be running at higher frequencies to service the
> > higher load periods, and low frequencies during lower load periods, which costs more energy than
> > running medium frequency the whole time and spreading out the load over the frame.
>
> My point is that even within 10ms, the optimal voltage will
> probably vary quite a bit (assuming fixed frequency).
Are you alluding to vdroop? This is a completely different discussion. The margins for efficiency gains are an order of magnitude lower than actual V/F switching.
>
> > >
> > > Generally the point is changing V/F should be inexpensive to enable using the optimal V/F combo.
> > >
> > > > So your 120MHz FIVR is completely and utterly pointless. You would be wasting energy at higher
> > > > voltages for no gain in user performance.
> > >
> > > Shifting to low voltage fast seems valuable, right?
> >
> > It doesn't because of the above reasons. You should be running
> > at the "just right" F/V servicing the workload.
>
> Let's say you are running at 2GHz. 8ms is 16M cycles. The 'best' voltage will
> vary over those 16M cycles based on activity in the chip, temperature, etc.
We already have these mechanisms in products right now / vdroop / temperature DVS. Yes you can have DVS that goes infinitely fast and does envelope tracking to the load. But that's a layer that sits underneath the DVFS logic.
>
> > > > Fmax should only every be reached and triggered after
> > > > continuous load of 2-3x of user experience window - current mobile phones do that in around 40-50ms,
> > > > anything faster than that is waste of energy and battery life. These are not HW limitations, but
> > > > learning the hard way what the most efficient way to design battery powered DVFS logic.
> > >
> > > Would that change if V/F switch took nanoseconds and cost little energy?
> > >
> > > Seems like you would want to dynamically adjust voltage...even if at fixed frequency.
> > >
> > > David
> >
> > If it would take nanoseconds to change V/F then all you're doing is having two states - Fmax and Fmin.
> > A that point Fmin becomes meaningless as a state and it's better to just clock gate/power gate. Your
> > most prevalent state in which you do computation would be Fmax and you defeat the purpose of DVFS.
>
> Well voltage can change quite rapidly. I think Intel's FIVR is around 1V
> in 0.5us. So if you wanted to change 50mV, that's probably quite quick.
>
> David
Again, I agree, but it's a different discussion topic. Currently vendors can't even rationalise dedicated voltage rails much less something like a FIVR - Qualcomm notes they use 1+3 on the same voltage rail because the increased capacitance of the larger rail brings more benefits than a dedicated rail. 50mV is an extremely excessive swing at constant frequency, but I guess it could happen on very high power cores, but that's a different market segment.
Topic | Posted By | Date |
---|---|---|
alder lake. | inteluser | 2021/09/10 01:52 AM |
alder lake. | Andrei F | 2021/09/10 09:31 AM |
alder lake. | Andrey | 2021/09/10 09:38 AM |
alder lake. | rwessel | 2021/09/10 11:18 AM |
alder lake. | Andrei F | 2021/09/10 12:49 PM |
alder lake. | Andrey | 2021/09/10 04:12 PM |
alder lake. | David Hess | 2021/09/10 07:39 PM |
alder lake. | Andrey | 2021/09/11 12:28 AM |
alder lake. | --- | 2021/09/10 05:24 PM |
alder lake. | Andrei F | 2021/09/12 01:09 AM |
DVFS | David Kanter | 2021/09/12 09:58 PM |
DVFS | Andrei F | 2021/09/13 01:02 AM |
DVFS | Anon | 2021/09/13 03:28 AM |
DVFS | Jukka Larja | 2021/09/13 05:35 AM |
DVFS | Andrei F | 2021/09/14 12:07 AM |
DVFS | Jukka Larja | 2021/09/14 04:11 AM |
DVFS | Andrei F | 2021/09/14 07:55 AM |
DVFS | Jukka Larja | 2021/09/14 10:23 AM |
DVFS | --- | 2021/09/13 10:19 AM |
DVFS | Doug S | 2021/09/13 10:57 AM |
DVFS | David Hess | 2021/09/13 11:32 AM |
DVFS | --- | 2021/09/13 01:06 PM |
DVFS | David Hess | 2021/09/13 02:21 PM |
DVFS | David Kanter | 2021/09/15 03:05 PM |
DVFS | David Hess | 2021/09/13 11:46 AM |
DVFS | Jukka Larja | 2021/09/14 04:35 AM |
Quick shutdown? | David Kanter | 2021/09/15 10:46 AM |
Quick shutdown? | Andrei F | 2021/09/16 07:12 AM |
Quick shutdown? | David Kanter | 2021/09/16 11:04 AM |
Quick shutdown? | Andrei F | 2021/09/17 01:35 AM |
Quick shutdown? | Andrei F | 2021/09/17 01:38 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 04:20 AM |
and weren't 'they' right? | Andrei F | 2021/09/13 04:51 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 06:29 AM |
and weren't 'they' right? | anon | 2021/09/13 05:07 AM |
and weren't 'they' right? | Jukka Larja | 2021/09/13 05:26 AM |
and weren't 'they' right? | anon | 2021/09/13 11:37 PM |
Alder Lake has no little cores | Heikki Kultala | 2021/09/13 06:33 AM |
Alder Lake has no little cores | Michael S | 2021/09/13 07:33 AM |
Alder Lake has no little cores | me | 2021/09/13 10:45 AM |
Alder Lake has no little cores | Heikki Kultala | 2021/09/13 01:49 PM |
Alder Lake has no little cores | anon | 2021/09/13 11:42 PM |
why stop at two core sizes? | hobold | 2021/09/14 05:47 AM |
Memory caches did this, right? | Mark Roulo | 2021/09/14 02:51 PM |
Memory caches did this, right? | Brett | 2021/09/14 07:17 PM |
Memory caches did this, right? | Kevin G | 2021/09/16 03:10 PM |
Large reorder buffers (L1+L2) | ⚛ | 2021/09/15 11:24 AM |
Large reorder buffers (L1+L2) | hobold | 2021/09/15 12:06 PM |
Alder Lake has no little cores | Adrian | 2021/09/14 08:33 AM |
and weren't 'they' right? | David Hess | 2021/09/13 12:00 PM |
Battery vs Performance | Mark Roulo | 2021/09/13 12:18 PM |
Battery vs Performance | Doug S | 2021/09/13 02:05 PM |
Battery vs Performance | David Hess | 2021/09/13 02:28 PM |
Battery vs Performance | --- | 2021/09/13 05:08 PM |
Battery vs Performance | --- | 2021/09/13 05:08 PM |
Battery vs Performance | Doug S | 2021/09/13 08:53 PM |
Battery vs Performance | Anon | 2021/09/14 06:42 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 12:57 PM |
and weren't 'they' right? | David Hess | 2021/09/13 02:11 PM |
and weren't 'they' right? | --- | 2021/09/13 02:38 PM |
and weren't 'they' right? | --- | 2021/09/13 02:32 PM |
and weren't 'they' right? | Brendan | 2021/09/14 03:30 AM |
and weren't 'they' right? | Jukka Larja | 2021/09/14 04:31 AM |
and weren't 'they' right? | Etienne Lorrain | 2021/09/14 12:29 AM |