On 2011-05-29 00:08, Gilles Chanteperdrix wrote: > On 05/28/2011 04:32 PM, 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. > > Last time I looked at CONFIG_NO_HZ, it did not look as Xenomai one-shot > timer at all. The system still had a periodic timer ticking HZ times by > second, in order to handle the non-high resolution timers. And this > timing was entirely disabled only when the system was idle. So, in other > word, the Linux kernel still needed a periodic timer interrupt.
Linux (with some architectural exceptions) no longer needs high-rate timer ticks for time keeping. Of course, if you miss timer events due to high Xenomai activity (or overload of the host machine when running as a VM), that's not good for reactivity and may have other side effects. > >> >>> When you run a >>> real-time task during 2 milliseconds and prevent the kernel from >>> receiving the timer interrupts, you certainly disrupt its timekeeping. >>> If you want to do this, switch the Linux kernel frequency (CONFIG_HZ) to >>> 100. >> >> Time keeping can perfectly bridge a lot of missing ticks as far as the >> underlying clocksource allows. And that's quite a bit with the x86 TSC. > > Here, we are asking it to only receive one interrupt over two. I have to > admit that I talked without testing, but as long as we do not test the > kernel behaviour in order to test whether it allows such disruption, I > find it safer to advise people not to disrupt it. I'm not suggesting people can now safely write RT hogs. But I don't think the overload scenario here should be responsible for the clock drift. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
