[EMAIL PROTECTED](Klaus Schmidinger) 02.12.07 14:47
>On 12/02/07 14:34, Darren Salt wrote:
>> I demand that Klaus Schmidinger may or may not have written...
>>> While testing this, I found that on my system the monotonic clock
>>> only has a resolution of 4000250 ns (about 4 ms), which in your
>>> original patch would have caused VDR not to use the monotonic
>> That suggests that your kernel is built with HZ=250 (CONFIG_HZ in
>I'm running the default SUSE 10.2 kernel.
>>> Are there actually systems that have a 1 ms resolution?
>> Any with HZ=1000, I expect :-)
>Ok, I see.
>I'll make it a 5 ms limit then, to allow default kernels to work.
For delays of under about 50 milliseconds (depending on the speed of your
processor and machine, and the system load), giving up the CPU takes too much
time, because the Linux scheduler (for the x86 architecture) usually takes at
least about 10-30 milliseconds before it returns control to your process. Due
to this, in small delays, usleep(3) usually delays somewhat more than the
amount that you specify in the parameters, and at least about 10 ms.
So i assume it's not just a problem of the "ticks intervall".
Too it might be required to differ between "wall clock" and "time delays".
VDR is (IMOH) a "strong(hard?) real time" application, not just another
file manager with a video interface ;-)
I wonder why linux "high resolution timer" can't be used for timeout and
I assume that those timer uses CPU/ACPI counters and not
the good old interrupt ticker which origins in a time when a tick faster
than 10ms would allocate the entire CPU and were never intented
to be used in "real time" applications.
So 10ms "sleep" would always be a 10ms sleep. not a 0ms or 5ms or 15ms
or 20ms, depending when the last tick occured and whichintervall was
What if the CPU clock is modulated to save power?
vdr mailing list