On 11/29/2013 06:36 PM, Carsten Emde wrote: > Hi Gilles, > >> On 11/29/2013 05:36 PM, Gilles Chanteperdrix wrote: >>> On 11/29/2013 04:10 PM, Carsten Emde wrote: >>>> BTW: Power saving and real-time do not necessarily exclude each other. >>>> If a - still deterministic - but a little longer latency is acceptable, >>>> some light sleep states and a somewhat lower clock frequency may be >>>> allowed which still may result in considerable energy saving. If, >>>> however, the fastest possible real-time response is required, C states >>>> and P states must be disabled (or set to polling and maximum speed, >>>> respectively) and the power bill must be payed. >>> Well, I do not fully agree. To be sure that you can clock down the >>> processor for executing a task which has sufficient time to meet its >>> deadline, your system must be "time triggered", all the timer events >>> must be known in advance. Because on a fully dynamic system, you may >>> make that decision, but a new timer may be scheduled which causes the >>> system to miss its deadline whereas it would not have missed it if it >>> had run at full speed. >> And a second problem is that you must know the task WCET, which on a >> modern system: >> - depends on the task frequency; >> - depends on the IRQ load. >> Again, only a time triggered system seems to make this possible. > Hmm, I'm not sure whether I correctly got your point. > > Let me try an example: A 1-GHz CPU of a given systems runs at full speed > with frequency governor set to performance and provides the required > real-time capabilities. When a second system with the same capabilities > was needed, the 1-GHz CPU unfortunately was out of stock, and the > decision was made to buy the 2-GHz variant of the processor. To save > energy, however, the clock frequency of the second system was set to 1 > GHz using the cpufreq interface. Are you arguing that the 2-GHz > processor that is throttled down to 1 GHz has a slower response time > than the 1-GHz processor that always runs at full speed? I probably misread what you were saying and thought you were talking about dynamically changing the processor frequency when knowing that the WCET of a task allows running it with a smaller frequency and still meet its deadline. The thing implemented here for instance: https://code.google.com/p/xenomaiote/ So called OTE algorithm (but I do not find what this acronym means exactly). -- Gilles. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
