Anders Blomdell wrote: > Jan Kiszka wrote: >> Anders Blomdell wrote: >> >>> Jan Kiszka wrote: >>> >>>> ...and may also add further latencies with the system has to speed up >>>> again. Anyway, there might be use-cases where power consumption is - >>>> besides latency - also an important issue. I'm just thinking of our >>>> smaller mobile robots where the power demand of the drives and the >>>> controller are not that far apart as on the larger platforms. >>>> >>>> What about other time sources on x86? Which systems already have HPET >>>> these days, and does this source not suffer from frequency scaling? I >>>> once read that HPET is quite easy to program, is this true? IOW, would >>>> it be worth considering to add this to the HAL? >>> >>> If it an computer with ACPI (which is very likely), one could use the PM >>> Timer (3.579545 MHz) as the base system clock, and sync with TSC at >>> every clockscaling and power events (the reason for that is that PM >>> Timer reads are quite slow (around 1 microsecond on the hardwares I >>> have tested), so most timer stuff should go via TSC). >>> >>> The advantage with this is that the system will keep accurate time even >>> in the low power modes (when TSC is turned off). I have done a crude >>> implementation of this on KURT (http://www.ittc.ku.edu/kurt/), and it is >>> a workable solution >> >> >> Oh, KURT still exists? Appeared a bit unmaintained to me last time I >> checked. > Maintained, but results are unfortunately not propagated to their > homepage. We are currently running a 2.6.12 version, which is (for our > purposes) essentially is Ingo Molnars patches + microsecond timer > resolution.
But I guess you are then running a quite old version of the RT-patch-set. Or is there still anything in the utime-patches (besides your PM-add-on) that the hrtimer does not provide? Cannot imagine because Thomas (Gleixner) was so deeply involved in KURT that he will likely have extracted all relevant features for his hrtimers. > >>> There are also good research/development oppurtunities in: >>> >>> 1. scheduling ACPI wakeup from those low-power modes in such good >>> time that all realtime requirements are met :-) >>> 2. scheduling of clockscaling changes to make minimum impact >>> on realtime tasks >>> >>> (For ACPI, see http://www.acpi.info/DOWNLOADS/ACPIspec30a.pdf) >>> >> >> >> Hmm, though likely feasible, this sounds like it requires some effort, >> especially the infrastructure to access ACPI directly (I guess we would >> still have to switch it off for Linux, wouldn't we?) and to set up the >> power event hooks. > Or present our own virtual ACPI controller to Linux, and enforce our > timing constraints while trying to keep power as low as Linux want us to. Hmm, sounds again like a lot of work - but it's attractive because it would be clean. ;) > >> How much code was involved in your KURT add-on? Can >> you extract it as a patch to asses the required work? I'm not planing to >> work on this, but if it is not too complicated, someone may once pick it >> up and integrate it in Xenomai. > I guess this is approximately the patch (which always reads the PM > Timer, which is not good for performance). It also does nothing to > prevent Linux from doing Power management, the only thing it does, is to > keep wall time and computer time in sync. Ah, these patches do not look that complicated. If I find some time to study them, I may come up with further questions. Thanks, Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
