From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43E2A31D.9000807@domain.hid> Date: Thu, 02 Feb 2006 17:26:05 -0700 From: Jim Cromie MIME-Version: 1.0 Subject: Re: [Xenomai-core] some results on my laptop References: <43E288AA.3050203@domain.hid> <43E28EE8.3020103@domain.hid> In-Reply-To: <43E28EE8.3020103@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: xenomai@xenomai.org 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 [jimc@domain.hid 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