Am 30.05.2011 12:33, schrieb Pavel Machek:
On Mon 2011-05-30 12:31:16, Jonas Witt wrote:
Am 30.05.2011 09:57, schrieb Jan Kiszka:
On 2011-05-30 09:43, Jonas Witt wrote:
Am 30.05.2011 09:07, schrieb Jan Kiszka:
On 2011-05-30 09:03, Pavel Machek wrote:
On Sat 2011-05-28 16:32:45, Jan Kiszka wrote:
On 2011-05-27 21:11, Gilles Chanteperdrix wrote:
On 05/27/2011 08:29 PM, Jonas Witt wrote:
Sorry, I missed the NTP-part. I am not using NTP. Just plain timer
queries on a single system.
My clock source is tsc which is the same for Xenomai I suppose.
I wonder how a Xenomai task, even if it occupies 50% or even 90%
of a 4
milliseconds time slice can interfere with the tsc. The tsc is not
incremented via an interrupt, is it? But I do not know much about the
inner workings of these functions.
The problem is not the clocksource, the problem is the timer
interrupt.
The kernel expects 1 timer tick every millisecond.
Not on archs that are CONFIG_NO_HZ capable.
Umm. NO_HZ is only active while system is idle. Kernel will still
expect the periodic ticks when CPU is busy....
(I'm not sure how the compensation works; perhaps it can compensate
even while busy..)
See update_wall_time, the !CONFIG_ARCH_USES_GETTIMEOFFSET includes no
fixed tick length.
Again, this is also important for Linux when running over hypervisors
which tend to miss ticks on overcommitment as well.
Jan
Thanks for the active discussion of the issue. I attached my config.
CONFIG_NO_HZ is activated and I think I disabled all power management
and frequency scaling correctly. Do you think it is worth trying a
kernel with fixed Hz as Gilles suggested? Actually the 1ms Xenomai load
seems to play at least some role in the issue.
For sure, I may also be proven wrong by plain reality.
In addition, enable CONFIG_PM and ACPI with the exception of
ACPI_PROCESSOR. Who knows what your BIOS is doing in the absence of OS
support for this.
Jan
I just compiled another kernel with an alternate configuration as
you and Gilles described (see the attached file). Now this is the
result:
# ./clocktest
== Tested clock: 0 (CLOCK_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 -1004111.0 0.026 0 0.00
1 -1004110.4 0.025 0 0.0
Looks perfect now (even with 2500us processing of 4000us periods)! A
big thank you to all of you. So either the 100Hz changed the
situation or the ACPI changes. The secondary mode switches for my
XenoQueue are still there, though. I will work on a minimal test
program to reproduce this. Thanks again! Do you think this
configuration advice should be put somewhere for others to read?
If you could verify config with 100Hz but no ACPI changes, that would
be great...
I just built another kernel with power management completely disabled
and got similar timing results. So it actually seems to be related to
timer interrupts that are missed in the 1000Hz setting as Gilles suggested.
Jonas
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
