Re: [Xenomai-help] [testsuite/latency] intervals are much than 1 second
Hello all, I have been out of xeno-scope for a while so maybe I successufy missed something important that might be the explanation of a problem described below. The problem is as follows: x86-ipipe-1.0.10 xenomai-2.1 (CVS: ~ November, 21) testsuite/letency is used as it is by defaulty (nsamples = 1 billion (1 second) / sample (e.g.10 us)) I am used to getting data with ~1-second-interval on the screen when latency is running and so expected to observe the same behaviour now. Nevertheless, the interval (with all parameters by default) is ~ 4 seconds, and it gets up to 16-17 seconds when -p 1000 (sampling period == 1 ms.) is used. e.g. it took 1 minute and 30 seconds to get 21 lines of statistics on the screen (-p 100) but should have been ~22-23 seconds. And the latency thread really reported the presence of collected data 21 times (through rt_sem_v()) . So have I missed something important? any ideas are wellcome. Dunno yet, but this reminds me of a trap I've been into recently thatcaused a massive slowdown of the latency test (v2.0.x) whilst thereported real-time activity seemed to be ok. Weird enough, actually. The explanation was that I mistakenly left the full ACPI support and SUSPENDactive in my kernel config (Asus box with ICH6 chipset). Shutting themdown solved the issue. I've not investigated further which one of the ACPI options or SUSPEND caused that trouble yet. Thanks for a hint. I have mistakenly used an improper .config as a base for the recently built xeno-aware kernel. ACPI support was on. Yep, it seemed the flow of time was ~4 times slower than normally but no overruns were encountered. --Philippe.-- Best regards,Dmitry Adamushko
Re: [Xenomai-help] [testsuite/latency] intervals are much than 1 second
Philippe Gerum wrote: Dmitry Adamushko wrote: Hello all, e.g. it took 1 minute and 30 seconds to get 21 lines of statistics on the screen (-p 100) but should have been ~22-23 seconds. And the latency thread really reported the presence of collected data 21 times (through rt_sem_v()) . So have I missed something important? any ideas are wellcome. Dunno yet, but this reminds me of a trap I've been into recently that caused a massive slowdown of the latency test (v2.0.x) whilst the reported real-time activity seemed to be ok. Weird enough, actually. The explanation was that I mistakenly left the full ACPI support and SUSPEND active in my kernel config (Asus box with ICH6 chipset). Shutting them down solved the issue. I've not investigated further which one of the ACPI options or SUSPEND caused that trouble yet. I am observing a similar issue here; after a suspend/resume cycle, running the latency test gives low latencies and every second is at least two seconds long. If I load the cpufreq module, I notice that even if when suspending, /proc/cpuinfo indicates 1.5 GHz, after resuming, it indicates 600 MHz. So, maybe, when doing a suspend/resume cycle without the CPUFreq modules loaded, Linux assumes that the CPU frequency remains the same whereas ACPI/BIOS changes it ? -- Gilles Chanteperdrix. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [testsuite/latency] intervals are much than 1 second
Philippe Gerum wrote: Dmitry Adamushko wrote: Hello all, e.g. it took 1 minute and 30 seconds to get 21 lines of statistics on the screen (-p 100) but should have been ~22-23 seconds. And the latency thread really reported the presence of collected data 21 times (through rt_sem_v()) . So have I missed something important? any ideas are wellcome. Dunno yet, but this reminds me of a trap I've been into recently that caused a massive slowdown of the latency test (v2.0.x) whilst the reported real-time activity seemed to be ok. Weird enough, actually. The explanation was that I mistakenly left the full ACPI support and SUSPEND active in my kernel config (Asus box with ICH6 chipset). Shutting them down solved the issue. I've not investigated further which one of the ACPI options or SUSPEND caused that trouble yet. I am observing a similar issue here; after a suspend/resume cycle, running the latency test gives low latencies and every second is at least two seconds long. If I load the cpufreq module, I notice that even if when suspending, /proc/cpuinfo indicates 1.5 GHz, after resuming, it indicates 600 MHz. So, maybe, when doing a suspend/resume cycle without the CPUFreq modules loaded, Linux assumes that the CPU frequency remains the same whereas ACPI/BIOS changes it ? -- Gilles Chanteperdrix.
