Re: [codec] #16: Multicast?

[Jean-Marc Valin <[e-mail]>]

Christian, please leave semiconductor physics out of this. FYI, see below:

On 10-05-27 06:45 AM, Christian Hoene wrote:
> Regarding Moore-law and so: We shall keep in mind that cannot continue forever. Already today, due to Quantum tunneling and
> subthreshold leakage current very small semiconductor structures consume increasing amounts of energy. Thus, it might not always be
> advisable to use the latest technology if power consumption shall be low.

Although power no longer scales linearly with the area of the 
transistors, it still decreases when one uses a smaller technology (with 
the exception being the huge leakage from 65 nm).

> It is know that "CMOS circuits dissipate power by charging the various load capacitances (mostly gate and wire capacitance, but also
> drain and some source capacitances) whenever they are switched. The charge moved is the capacitance multiplied by the voltage
> change. Multiply by the switching frequency on the load capacitances to get the current used, and multiply by voltage again to get
> the characteristic switching power dissipated by a CMOS device: P = CV²f".
> ...
> Thus, the power does not decrease if the calculation (e.g., the encoding and decoding) is done faster or slower.

Euh?? what about f? That's the part that takes into account faster vs 
slower. Even if you don't change the clock, the amount of calculations 
you have still has an impact on power. Once you've paid for the idle 
(static) power, the dynamic power is pretty much proportional to how 
fast you do your calculation. That being said, there's also about 100 
other factors involved in the power consumption, including the 
technology used (low/standard/high threshold gates), tons of 
architectural decisions (cache, branch prediction, parallelism, ...), 
power-saving features, and so on.

> In order to save power in mobile device, Dynamic frequency scaling and Dynamic voltage scaling change the frequency and/or the
> voltage to save power.  If power consumption needs to be reduced, the device reduces voltage and frequency and thus the calculation
> takes longer. Thus, even if the CPU can do the encoding/decoding at full speed and in a fraction of the frame duration, it is not
> always advisable to do it like that. Instead, if energy supply is limited, then calculations shall be slowed down.

Many people have found that for a given CPU, it's very often more 
efficient to do the calculation at full-speed and then enter the 
low-power state as quickly as possible -- as opposed to making the 
calculation slower and being in low-power state for less time. The term 
for that is "race to idle".

> My argumentations above support the position of Raymond that device with low processing power will be used and that this increases
> to the transmission delay. However, I am not an expert in system or chip design and thus, I might have missed a few details or
> tradeoffs.

No need to go into chip design to say that "lower complexity is better". 
The key is deciding what's acceptable and what's the tradeoff. If 
complexity was the only issue, we'd all be using G.711. No matter what 
the final complexity will be, there will be chips that aren't powerful 
to execute it and there will be chips that are so powerful that they 
don't wouldn't notice if the complexity doubled.

Cheers,

	Jean-Marc