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...
Pavel
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
