On 2011-05-30 14:32, Jonas Witt wrote: > 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.
Weird and not explainable. I'm currently running a RT CPU hog that eats 500 ms of each second on a single-core x86-64 box, and clocktest reports the very same drift as without any load. I'll see if I can give your .config a try later on. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
