Klaus.Schmidinger@xxxxxxxxxx(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... >> >> [snip] >>> 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 >>> clock. >> >> That suggests that your kernel is built with HZ=250 (CONFIG_HZ in >> /proc/config.gz). >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. http://tldp.org/HOWTO/IO-Port-Programming-4.html 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 delay timings. 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. See http://www.opengroup.org/rtforum/jan2002/slides/linux/mehaffey.pdf etc. 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 choosen. Another question: What if the CPU clock is modulated to save power? _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
