By: Andrei F (andrei.delete@this.anandtech.com), September 13, 2021 1:02 am
Room: Moderated Discussions
David Kanter (dkanter.delete@this.realworldtech.com) on September 12, 2021 10:58 pm wrote:
> > One of the biggest issues that the traditional companies is that they have not understood power efficient
> > DVFS. Years ago, Intel engineers lambasted schemes like big.LITTLE because it was "not hardware controlled"
> > - but you precisely do not want ultra-fine grained DVFS like that for several reasons.
>
> >In battery powered
> > devices the whole point of DVFS was to avoid the higher
> > performance states and voltages as much as possible,
> > and what matters here is the delivery of performance within a unit of user experience, essentially a 16ms
> > or 8ms frame, which is AGES.
>
> Isn't the point to deliver max perf with min energy?
>
> >The act of frequency and voltage change itself takes up quite a bit of energy
> > and you literally do not want to do it that fast because it actually would be more efficient to smooth out
> > performance over the duration of your frame at a lower state, or clock/power-gate at smaller idle periods
> > rather than to DVFS down.
>
> That depends on several things:
>
> 1. Latency of adjusting voltage
> 2. Latency of adjusting the clock
> 3. Penalties associated with changing V or F
>
> For a system with a 120MHz FIVR, you can adjust voltage pretty quickly compared to that 8ms period.
>
> It is quite possible to change clocks in a small number of cycles, depending on your clocking architecture.
>
> Again - if you look at an 8ms period, that's 24M clock cycles. I think burning around 1-2% of those on voltage
> and frequency transition shouldn't be an issue compared to possible gains, although this is a guess.
>
> One issue is that I suspect many designs impose long penalties for
> voltage/clock transitions. But that's a choice, not a limitation.
>
> David
> 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*.
So your 120MHz FIVR is completely and utterly pointless. You would be wasting energy at higher voltages for no gain in user performance. 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.
> > One of the biggest issues that the traditional companies is that they have not understood power efficient
> > DVFS. Years ago, Intel engineers lambasted schemes like big.LITTLE because it was "not hardware controlled"
> > - but you precisely do not want ultra-fine grained DVFS like that for several reasons.
>
> >In battery powered
> > devices the whole point of DVFS was to avoid the higher
> > performance states and voltages as much as possible,
> > and what matters here is the delivery of performance within a unit of user experience, essentially a 16ms
> > or 8ms frame, which is AGES.
>
> Isn't the point to deliver max perf with min energy?
>
> >The act of frequency and voltage change itself takes up quite a bit of energy
> > and you literally do not want to do it that fast because it actually would be more efficient to smooth out
> > performance over the duration of your frame at a lower state, or clock/power-gate at smaller idle periods
> > rather than to DVFS down.
>
> That depends on several things:
>
> 1. Latency of adjusting voltage
> 2. Latency of adjusting the clock
> 3. Penalties associated with changing V or F
>
> For a system with a 120MHz FIVR, you can adjust voltage pretty quickly compared to that 8ms period.
>
> It is quite possible to change clocks in a small number of cycles, depending on your clocking architecture.
>
> Again - if you look at an 8ms period, that's 24M clock cycles. I think burning around 1-2% of those on voltage
> and frequency transition shouldn't be an issue compared to possible gains, although this is a guess.
>
> One issue is that I suspect many designs impose long penalties for
> voltage/clock transitions. But that's a choice, not a limitation.
>
> David
> 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*.
So your 120MHz FIVR is completely and utterly pointless. You would be wasting energy at higher voltages for no gain in user performance. 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.
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 |