Re: [Xenomai-core] some results on my laptop
Philippe Gerum wrote: Jim Cromie wrote: Philippe Gerum wrote: Ive been running an ipipe kernel as the default since shortly after 1/7. Since then, Ive had a couple of freezes on boot, and sometimes bash's auto-complete takes longer to complete, Eh? Maybe the CONFIG_PCI_MSI syndrom again? Um, does this tell you anything ? $ zcat /proc/config.gz | grep PCI_MSI # CONFIG_PCI_MSI is not set I noticed the slow completion when doing some heavy disk stuff, lndir on a kernel tree, and probably diff -r on 2 kernel trees, so the laptop was pretty busy. This was run on a pentium-M laptop, with cpu-clock running at 600 MHz, (capable of 1.7 GHz) I presume this might explain the negative latancies. Im aware this is un-supported .. The negative values are just there because even at 600Mhz, the timing anticipation applied by the nucleus to compensate for the intrinsic latency of the box is too high; i.e. the nucleus performs a bit too well latency-wise, so the anticipated timer ticks end up being a bit early on schedule. IOW, all is fine. Given the figures above, you could probably reduce the anticipation factor by setting the CONFIG_XENO_HW_SCHED_LATENCY (Machine menu) parameter to, say, 2500 nanoseconds (the default null value tells the nucleus to use the pre-calibrated value, which might be higher than this for your setup). Ok. with latencies == 0, calibration happens at runtime, so it would reflect the current workload (and with cpufreq on) also would reflect the current clock frequency, correct ? With latency == 0, a pre-calibrated latency value is extracted from asm-i386/calibration.h. Btw, I'm not sure if you enabled the local APIC in your kernel config; if you did not, you should: there is no reason to keep using the braindamage 8254 PIT when a LAPIC is available with your CPU. Ok, now running this. zcat /proc/config.gz | grep APIC CONFIG_X86_GOOD_APIC=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y [EMAIL PROTECTED] latency]$ sudo ./run -- -T60 -s -t1 Password: * * * Type ^C to stop this application. * * == Sampling period: 100 us == Test mode: in-kernel periodic task warming up... RTT| 00:00:05 (in-kernel periodic task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -2165| 127216| 1399358|7582| -2165| 1399358 ACPI is still on, it seems. ACPI, and PM must be off. They are responsible for hw-generated latencies. Additionally, you may want to switch on the SMI disable option from the Xeno config, to see if things improve. If you are on a Pentium-M system, SMI disable is a must. RTD| -2188| -205817| 1403255| 16431| -2188| 1403255 RTD| -2178| -207605| 1399828| 25271| -2188| 1403255 RTD| -2186| -208602| 1402253| 34096| -2188| 1403255 RTD| -2163| -206835| 1399144| 42943| -2188| 1403255 RTD| -2175| -206848| 1401346| 51785| -2188| 1403255 RTD| -2184| -210270| 1396823| 60621| -2188| 1403255 RTD| -2167| -208781| 1399323| 69453| -2188| 1403255 RTD| -2169| -211121| 1397365| 78267| -2188| 1403255 RTD| -2173| -210119| 1398349| 87084| -2188| 1403255 RTD| -2168| -208425| 1400764| 95922| -2188| 1403255 RTD| -2173| 211271| 1397470| 104678| -2188| 1403255 RTD| -2170| -208130| 1399794| 113508| -2188| 1403255 RTD| -2161| -208400| 1397968| 122334| -2188| 1403255 RTD| -2162| -211225| 1397581| 131139| -2188| 1403255 RTD| -2175| -210500| 1397274| 139951| -2188| 1403255 RTD| -2179| -207530| 1396890| 148781| -2188| 1403255 RTD| -2178| -207890| 1399275| 157611| -2188| 1403255 RTD| -2172| -207750| 1397386| 166432| -2188| 1403255 RTD| -2175| -206057| 1399763| 175260| -2188| 1403255 HSH|--param|--samples-|--average--|---stddev-- HSS|min|20| 2.000| 0.000 HSS|avg|205060| 90.399| 25.538 HSS|max|20| 99.000| 0.000 ---|||||- RTS| -2188| -170670| 1403255| 175260|00:01:00/00:01:00 Obviously, the numbers dont look so good. The test duration comments still apply. You should disable the ACPI support if enabled, and especially everything related to the CPUfreq scaling and power suspend. Given that Im not really developing any RT code, and I like the laptop quiet and cool, Im inclined to keep the CPUfreq scaling on, at least for my everyday kernel. How much does
Re: [Xenomai-core] some results on my laptop
Jan Kiszka wrote: ... 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? There are actually only few registers: http://www.intel.com/hardwaredesign/hpetspec_1.pdf Even a replacement for the TSC is available (Main Counter), but I guess that some effort will be required to replace all direct usages of rdtsc in the current Xenomai code, right? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] some results on my laptop
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. 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. 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. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] some results on my laptop
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
Re: [Xenomai-core] xenomai posix build errs
Jim Cromie wrote: build error after selecting POSIX interface, on svn-head - ie 515 [EMAIL PROTECTED] linux-2.6.15.1-ipipe-103-sonyI]$ make CHK include/linux/version.h SPLIT include/linux/autoconf.h - include/config/* CHK include/linux/compile.h CHK usr/initramfs_list CC [M] kernel/xenomai/skins/posix/sched.o In file included from kernel/xenomai/skins/posix/../posix/internal.h:24, from kernel/xenomai/skins/posix/../posix/thread.h:23, from kernel/xenomai/skins/posix/sched.c:19: include/xenomai/posix/posix.h:43:19: error: errno.h: No such file or directory Could you try re-running prepare-kernel.sh ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] fix pthread cancellation in native skin
Philippe Gerum wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Gilles Chanteperdrix wrote: This is not the only situation where a thread with a nucleus suspension bit need to run shortly in secondary mode: it also occurs when suspending with xnpod_suspend_thread() a thread running in secondary mode; the thread receives the SIGCHLD signal and need to execute shortly with the suspension bit set in order to cause a migration to primary mode. So, the only case when we are sure that a user-space thread can not be scheduled by Linux seems to be when this thread does not have the XNRELAX bit. From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is set, a thread can not be running in secondary mode. Hence the proposed patch. Almost ok, but XNDELAY might also be set alone, indicating a purely timed wait state (i.e. without sync object to pend on, so XNPEND is off). Forget about this: XNDELAY might also be a transient bit like XNSUSP, so you are right, we cannot test it there. Ok. The patch is applied to svn trunk. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] some results on my laptop
Philippe Gerum wrote: Ive been running an ipipe kernel as the default since shortly after 1/7. Since then, Ive had a couple of freezes on boot, and sometimes bash's auto-complete takes longer to complete, Eh? Maybe the CONFIG_PCI_MSI syndrom again? Um, does this tell you anything ? $ zcat /proc/config.gz | grep PCI_MSI # CONFIG_PCI_MSI is not set I noticed the slow completion when doing some heavy disk stuff, lndir on a kernel tree, and probably diff -r on 2 kernel trees, so the laptop was pretty busy. This was run on a pentium-M laptop, with cpu-clock running at 600 MHz, (capable of 1.7 GHz) I presume this might explain the negative latancies. Im aware this is un-supported .. The negative values are just there because even at 600Mhz, the timing anticipation applied by the nucleus to compensate for the intrinsic latency of the box is too high; i.e. the nucleus performs a bit too well latency-wise, so the anticipated timer ticks end up being a bit early on schedule. IOW, all is fine. Given the figures above, you could probably reduce the anticipation factor by setting the CONFIG_XENO_HW_SCHED_LATENCY (Machine menu) parameter to, say, 2500 nanoseconds (the default null value tells the nucleus to use the pre-calibrated value, which might be higher than this for your setup). Ok. with latencies == 0, calibration happens at runtime, so it would reflect the current workload (and with cpufreq on) also would reflect the current clock frequency, correct ? Btw, I'm not sure if you enabled the local APIC in your kernel config; if you did not, you should: there is no reason to keep using the braindamage 8254 PIT when a LAPIC is available with your CPU. Ok, now running this. zcat /proc/config.gz | grep APIC CONFIG_X86_GOOD_APIC=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y [EMAIL PROTECTED] latency]$ sudo ./run -- -T60 -s -t1 Password: * * * Type ^C to stop this application. * * == Sampling period: 100 us == Test mode: in-kernel periodic task warming up... RTT| 00:00:05 (in-kernel periodic task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -2165| 127216| 1399358|7582| -2165| 1399358 RTD| -2188| -205817| 1403255| 16431| -2188| 1403255 RTD| -2178| -207605| 1399828| 25271| -2188| 1403255 RTD| -2186| -208602| 1402253| 34096| -2188| 1403255 RTD| -2163| -206835| 1399144| 42943| -2188| 1403255 RTD| -2175| -206848| 1401346| 51785| -2188| 1403255 RTD| -2184| -210270| 1396823| 60621| -2188| 1403255 RTD| -2167| -208781| 1399323| 69453| -2188| 1403255 RTD| -2169| -211121| 1397365| 78267| -2188| 1403255 RTD| -2173| -210119| 1398349| 87084| -2188| 1403255 RTD| -2168| -208425| 1400764| 95922| -2188| 1403255 RTD| -2173| 211271| 1397470| 104678| -2188| 1403255 RTD| -2170| -208130| 1399794| 113508| -2188| 1403255 RTD| -2161| -208400| 1397968| 122334| -2188| 1403255 RTD| -2162| -211225| 1397581| 131139| -2188| 1403255 RTD| -2175| -210500| 1397274| 139951| -2188| 1403255 RTD| -2179| -207530| 1396890| 148781| -2188| 1403255 RTD| -2178| -207890| 1399275| 157611| -2188| 1403255 RTD| -2172| -207750| 1397386| 166432| -2188| 1403255 RTD| -2175| -206057| 1399763| 175260| -2188| 1403255 HSH|--param|--samples-|--average--|---stddev-- HSS|min|20| 2.000| 0.000 HSS|avg|205060| 90.399| 25.538 HSS|max|20| 99.000| 0.000 ---|||||- RTS| -2188| -170670| 1403255| 175260|00:01:00/00:01:00 Obviously, the numbers dont look so good. The test duration comments still apply. You should disable the ACPI support if enabled, and especially everything related to the CPUfreq scaling and power suspend. Given that Im not really developing any RT code, and I like the laptop quiet and cool, Im inclined to keep the CPUfreq scaling on, at least for my everyday kernel. How much does CPUfreq invalidate results I might send (periodically) thanks
Re: [Xenomai-core] some results on my laptop
Jim Cromie wrote: Philippe Gerum wrote: Ive been running an ipipe kernel as the default since shortly after 1/7. Since then, Ive had a couple of freezes on boot, and sometimes bash's auto-complete takes longer to complete, Eh? Maybe the CONFIG_PCI_MSI syndrom again? Um, does this tell you anything ? $ zcat /proc/config.gz | grep PCI_MSI # CONFIG_PCI_MSI is not set I noticed the slow completion when doing some heavy disk stuff, lndir on a kernel tree, and probably diff -r on 2 kernel trees, so the laptop was pretty busy. This was run on a pentium-M laptop, with cpu-clock running at 600 MHz, (capable of 1.7 GHz) I presume this might explain the negative latancies. Im aware this is un-supported .. The negative values are just there because even at 600Mhz, the timing anticipation applied by the nucleus to compensate for the intrinsic latency of the box is too high; i.e. the nucleus performs a bit too well latency-wise, so the anticipated timer ticks end up being a bit early on schedule. IOW, all is fine. Given the figures above, you could probably reduce the anticipation factor by setting the CONFIG_XENO_HW_SCHED_LATENCY (Machine menu) parameter to, say, 2500 nanoseconds (the default null value tells the nucleus to use the pre-calibrated value, which might be higher than this for your setup). Ok. with latencies == 0, calibration happens at runtime, so it would reflect the current workload (and with cpufreq on) also would reflect the current clock frequency, correct ? With latency == 0, a pre-calibrated latency value is extracted from asm-i386/calibration.h. Btw, I'm not sure if you enabled the local APIC in your kernel config; if you did not, you should: there is no reason to keep using the braindamage 8254 PIT when a LAPIC is available with your CPU. Ok, now running this. zcat /proc/config.gz | grep APIC CONFIG_X86_GOOD_APIC=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y [EMAIL PROTECTED] latency]$ sudo ./run -- -T60 -s -t1 Password: * * * Type ^C to stop this application. * * == Sampling period: 100 us == Test mode: in-kernel periodic task warming up... RTT| 00:00:05 (in-kernel periodic task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -2165| 127216| 1399358|7582| -2165| 1399358 ACPI is still on, it seems. ACPI, and PM must be off. They are responsible for hw-generated latencies. Additionally, you may want to switch on the SMI disable option from the Xeno config, to see if things improve. RTD| -2188| -205817| 1403255| 16431| -2188| 1403255 RTD| -2178| -207605| 1399828| 25271| -2188| 1403255 RTD| -2186| -208602| 1402253| 34096| -2188| 1403255 RTD| -2163| -206835| 1399144| 42943| -2188| 1403255 RTD| -2175| -206848| 1401346| 51785| -2188| 1403255 RTD| -2184| -210270| 1396823| 60621| -2188| 1403255 RTD| -2167| -208781| 1399323| 69453| -2188| 1403255 RTD| -2169| -211121| 1397365| 78267| -2188| 1403255 RTD| -2173| -210119| 1398349| 87084| -2188| 1403255 RTD| -2168| -208425| 1400764| 95922| -2188| 1403255 RTD| -2173| 211271| 1397470| 104678| -2188| 1403255 RTD| -2170| -208130| 1399794| 113508| -2188| 1403255 RTD| -2161| -208400| 1397968| 122334| -2188| 1403255 RTD| -2162| -211225| 1397581| 131139| -2188| 1403255 RTD| -2175| -210500| 1397274| 139951| -2188| 1403255 RTD| -2179| -207530| 1396890| 148781| -2188| 1403255 RTD| -2178| -207890| 1399275| 157611| -2188| 1403255 RTD| -2172| -207750| 1397386| 166432| -2188| 1403255 RTD| -2175| -206057| 1399763| 175260| -2188| 1403255 HSH|--param|--samples-|--average--|---stddev-- HSS|min|20| 2.000| 0.000 HSS|avg|205060| 90.399| 25.538 HSS|max|20| 99.000| 0.000 ---|||||- RTS| -2188| -170670| 1403255| 175260|00:01:00/00:01:00 Obviously, the numbers dont look so good. The test duration comments still apply. You should disable the ACPI support if enabled, and especially everything related to the CPUfreq scaling and power suspend. Given that Im not really developing any RT code, and I like the laptop quiet and cool, Im inclined to keep the CPUfreq scaling on, at least for my everyday kernel. How much does CPUfreq invalidate results I might send (periodically) Well, it basically totally wrecks the timing... thanks -- Philippe.
Re: [Xenomai-core] some results on my laptop
Philippe Gerum wrote: Jim Cromie wrote: Philippe Gerum wrote: Ive been running an ipipe kernel as the default since shortly after 1/7. Since then, Ive had a couple of freezes on boot, and sometimes bash's auto-complete takes longer to complete, Eh? Maybe the CONFIG_PCI_MSI syndrom again? Um, does this tell you anything ? $ zcat /proc/config.gz | grep PCI_MSI # CONFIG_PCI_MSI is not set I noticed the slow completion when doing some heavy disk stuff, lndir on a kernel tree, and probably diff -r on 2 kernel trees, so the laptop was pretty busy. This was run on a pentium-M laptop, with cpu-clock running at 600 MHz, (capable of 1.7 GHz) I presume this might explain the negative latancies. Im aware this is un-supported .. The negative values are just there because even at 600Mhz, the timing anticipation applied by the nucleus to compensate for the intrinsic latency of the box is too high; i.e. the nucleus performs a bit too well latency-wise, so the anticipated timer ticks end up being a bit early on schedule. IOW, all is fine. Given the figures above, you could probably reduce the anticipation factor by setting the CONFIG_XENO_HW_SCHED_LATENCY (Machine menu) parameter to, say, 2500 nanoseconds (the default null value tells the nucleus to use the pre-calibrated value, which might be higher than this for your setup). Ok. with latencies == 0, calibration happens at runtime, so it would reflect the current workload (and with cpufreq on) also would reflect the current clock frequency, correct ? With latency == 0, a pre-calibrated latency value is extracted from asm-i386/calibration.h. Btw, I'm not sure if you enabled the local APIC in your kernel config; if you did not, you should: there is no reason to keep using the braindamage 8254 PIT when a LAPIC is available with your CPU. Ok, now running this. zcat /proc/config.gz | grep APIC CONFIG_X86_GOOD_APIC=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y [EMAIL PROTECTED] latency]$ sudo ./run -- -T60 -s -t1 Password: * * * Type ^C to stop this application. * * == Sampling period: 100 us == Test mode: in-kernel periodic task warming up... RTT| 00:00:05 (in-kernel periodic task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -2165| 127216| 1399358|7582| -2165| 1399358 ACPI is still on, it seems. ACPI, and PM must be off. They are responsible for hw-generated latencies. Additionally, you may want to switch on the SMI disable option from the Xeno config, to see if things improve. If you are on a Pentium-M system, SMI disable is a must. RTD| -2188| -205817| 1403255| 16431| -2188| 1403255 RTD| -2178| -207605| 1399828| 25271| -2188| 1403255 RTD| -2186| -208602| 1402253| 34096| -2188| 1403255 RTD| -2163| -206835| 1399144| 42943| -2188| 1403255 RTD| -2175| -206848| 1401346| 51785| -2188| 1403255 RTD| -2184| -210270| 1396823| 60621| -2188| 1403255 RTD| -2167| -208781| 1399323| 69453| -2188| 1403255 RTD| -2169| -211121| 1397365| 78267| -2188| 1403255 RTD| -2173| -210119| 1398349| 87084| -2188| 1403255 RTD| -2168| -208425| 1400764| 95922| -2188| 1403255 RTD| -2173| 211271| 1397470| 104678| -2188| 1403255 RTD| -2170| -208130| 1399794| 113508| -2188| 1403255 RTD| -2161| -208400| 1397968| 122334| -2188| 1403255 RTD| -2162| -211225| 1397581| 131139| -2188| 1403255 RTD| -2175| -210500| 1397274| 139951| -2188| 1403255 RTD| -2179| -207530| 1396890| 148781| -2188| 1403255 RTD| -2178| -207890| 1399275| 157611| -2188| 1403255 RTD| -2172| -207750| 1397386| 166432| -2188| 1403255 RTD| -2175| -206057| 1399763| 175260| -2188| 1403255 HSH|--param|--samples-|--average--|---stddev-- HSS|min|20| 2.000| 0.000 HSS|avg|205060| 90.399| 25.538 HSS|max|20| 99.000| 0.000 ---|||||- RTS| -2188| -170670| 1403255| 175260|00:01:00/00:01:00 Obviously, the numbers dont look so good. The test duration comments still apply. You should disable the ACPI support if enabled, and especially everything related to the CPUfreq scaling and power suspend. Given that Im not really developing any RT code, and I like the laptop quiet and cool, Im inclined to keep the CPUfreq scaling on, at least for my everyday kernel. How much does
Re: [Xenomai-core] some results on my laptop
Jan Kiszka wrote: ... 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? There are actually only few registers: http://www.intel.com/hardwaredesign/hpetspec_1.pdf Even a replacement for the TSC is available (Main Counter), but I guess that some effort will be required to replace all direct usages of rdtsc in the current Xenomai code, right? Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] some results on my laptop
Jan Kiszka wrote: Jan Kiszka wrote: ... 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? There are actually only few registers: http://www.intel.com/hardwaredesign/hpetspec_1.pdf Even a replacement for the TSC is available (Main Counter), but I guess that some effort will be required to replace all direct usages of rdtsc in the current Xenomai code, right? There should not be any direct usage, at least into the generic code, since it is aimed at running over the event-driven simulator too. Actually, the same goes for the x86-specific code, since we do support using the 8254 as an alternative to the TSC. Jan -- Philippe.
Re: [Xenomai-core] some results on my laptop
Jan Kiszka wrote: Jan Kiszka wrote: ... 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? There are actually only few registers: http://www.intel.com/hardwaredesign/hpetspec_1.pdf Even a replacement for the TSC is available (Main Counter), but I guess that some effort will be required to replace all direct usages of rdtsc in the current Xenomai code, right? And unfortunately they aren't guaranteed to survive S3 sleep, which laptops spend a lot of time in (around 50% when doing coantrol at 100 Hz). -- Anders
Re: [Xenomai-core] some results on my laptop
Anders Blomdell wrote: Jan Kiszka wrote: Jan Kiszka wrote: ... 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? There are actually only few registers: http://www.intel.com/hardwaredesign/hpetspec_1.pdf Even a replacement for the TSC is available (Main Counter), but I guess that some effort will be required to replace all direct usages of rdtsc in the current Xenomai code, right? And unfortunately they aren't guaranteed to survive S3 sleep, which laptops spend a lot of time in (around 50% when doing coantrol at 100 Hz). Great. Someone should go out and choke a few hardware developers again for being that short-sighted. So the PM timer is the most robust one, just a bit slow. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] some results on my laptop
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. 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. 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. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] some results on my laptop
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
