Hi,
With vdr 1.4.5 + dvd, dvdselect and subtitles plugins I sometimes get the following when vdr tries to set the System time.
May 31 20:23:35 localhost vdr: [3405] switching to channel 1 May 31 20:23:35 localhost vdr: [3405] timer 1 (3 2056-2210 'News') set to event Thu 31.05.2007 21:00-22:00 'News' May 31 20:23:38 localhost vdr: [3413] System Time = Thu May 31 20:23:38 2007 (1180632218) May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007 (1180631977) May 31 20:21:01 localhost vdr: [3405] PANIC: watchdog timer expired - exiting!
Could vdr turn off the watchdog before it sets the system time, if that is the problem?
Josce
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Unknown Unknown wrote:
May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007 (1180631977) May 31 20:21:01 localhost vdr: [3405] PANIC: watchdog timer expired - exiting!
Could vdr turn off the watchdog before it sets the system time, if that is the problem?
IMHO the alert function should work based on the time-since-boot clock, not relative to the calendar clock. The watchdog did not fire on my machine while I was playing with the clock.
However, there are some other clock-dependent things in VDR that are not designed to handle larger clock jumps. Usually, clock jumps should be just a few seconds, and only after starting VDR.
You should investigate what causes the clock to jump 4 minutes. If your PC clock is THAT bad, its probably worth dumping the mainboard - you do want recordings in time, do you? If this is due to different clocks on transponders, you should restrict the clock sync to a single transponder. (settings -> EPG)
Cheers,
Udo
Hi
By the way, I have another question about clock and vdr, I have put vdr setting to synchronise time with a specific channel and setup vdr to start on this channel. Unfortunately , when vdr start, the system is never on time, at least there is two hours minus. The main problem is that vdr look at schedule and if there is one setup at this time, even if this is wrong time, system records
Example to be more clear :
schedule 18H/20H current national time (GMT+2) = 21H rebooting vdr and computer current bios time is 19H the system records my scheduled program (range 18/20)
Is there a way to force vdr to first update system time to transponder time as design and after look if something is really scheduled ?
Thanks for help
Le mardi 5 juin 2007 19:26, Udo Richter a écrit :
Unknown Unknown wrote:
May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007 (1180631977) May 31 20:21:01 localhost vdr: [3405] PANIC: watchdog timer expired - exiting!
Could vdr turn off the watchdog before it sets the system time, if that is the problem?
IMHO the alert function should work based on the time-since-boot clock, not relative to the calendar clock. The watchdog did not fire on my machine while I was playing with the clock.
However, there are some other clock-dependent things in VDR that are not designed to handle larger clock jumps. Usually, clock jumps should be just a few seconds, and only after starting VDR.
You should investigate what causes the clock to jump 4 minutes. If your PC clock is THAT bad, its probably worth dumping the mainboard - you do want recordings in time, do you? If this is due to different clocks on transponders, you should restrict the clock sync to a single transponder. (settings -> EPG)
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
PLU Dominique wrote:
Is there a way to force vdr to first update system time to transponder time as design and after look if something is really scheduled ?
You could use a tool like dvbdate to update the clock before starting VDR.
If you have a permanent Internet connection, or at least some local LAN server with a better clock, you can use NTP to synchronize the clock.
Another idea is to use some tool to correct constant clock drift. This should get your clock quite well, if the clock drift is constant, like 5 minutes per day. (The ntpd time server has a built-in drift correction, but of course requires another exact time source)
Cheers,
Udo
On 06/05/07 19:47, PLU Dominique wrote:
Hi
By the way, I have another question about clock and vdr, I have put vdr setting to synchronise time with a specific channel and setup vdr to start on this channel. Unfortunately , when vdr start, the system is never on time, at least there is two hours minus....
Are you sure you have set the correct time zone?
Klaus
Hi
Currently, no, the TZ is set to GMT , the solution is to change it but it will not resolve entierly the problem, when I shutdown the system, the clock of another computer miss many days or year, meaning bios battery is dead and as long this battery is not standard (std=cr2032 or equiv) I cannot change it
I was just hoping that the system could first synchronize the system time to transponder inside the init phase and after start operation like schedule. Maybe in future release ?
By the way, I will follow the recommandation of Udo Richter and going to ntp solution if I can adapt to my slack/vdrlive system
Thanks for your help and time
Le mercredi 6 juin 2007 19:04, Klaus Schmidinger a écrit :
On 06/05/07 19:47, PLU Dominique wrote:
Hi
By the way, I have another question about clock and vdr, I have put vdr setting to synchronise time with a specific channel and setup vdr to start on this channel. Unfortunately , when vdr start, the system is never on time, at least there is two hours minus....
Are you sure you have set the correct time zone?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Well if the PC clock was correct all the time I would probably not have to use the set time function :)
Yes, but typically PC HW clock does not drift so much. You could use hwclock --systohc (and possibly --utc or --localtime) after letting the vdr to set the system clock.
I am sure this would fix the problem. However, is this really the way it should work? The clock is four minutes off, let's PANIC?
To be honest, I have seen a lot of worse PC clocks around than the one I have on my spare computer ...
Josce
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Josce Unknown schrieb:
Well if the PC clock was correct all the time I would probably not have to use the set time function :)
Yes, but typically PC HW clock does not drift so much. You could use hwclock --systohc (and possibly --utc or --localtime) after letting the vdr to set the system clock.
I am sure this would fix the problem. However, is this really the way it should work? The clock is four minutes off, let's PANIC?
To be honest, I have seen a lot of worse PC clocks around than the one I have on my spare computer ...
Josce
Hi all, Josc, i would say your oppinion is correct, the real problem here is not the clock beeing off 4 Minutes, it is the way vdr changes the local clock without noticing his internal watchdog about this discontinuit in the timebase. I would call it a bug. either it should adjust the clock in steps of a few seconds like ntpd does or it should tell his own watchdog to ignore this "jump" in time. Christoph
Josce Unknown wrote:
I am sure this would fix the problem. However, is this really the way it should work? The clock is four minutes off, let's PANIC?
VDR still defaults to start recordings three minutes before scheduled time, right? I wouldn't want to rely my recordings on a clock that is that bad.
To be honest, I have seen a lot of worse PC clocks around than the one I have on my spare computer ...
The worst I had was on a 286, running 40s off per day. Good thing that this is over. Today, I would count one or two minutes per month as worst acceptable.
Back on the issue:
I've just tested this on my machine, with a small program that uses the alarm() to sleep for 10 seconds, just as the watchdog uses alarm(). (Code is attached.) This is a normal run:
#>date ; ./alarm ; date Sa 9. Jun 11:50:36 CEST 2007 alarm Sa 9. Jun 11:50:46 CEST 2007
The second run, I started the program at 11:52:55, and at 11:53 I manually changed the clock to 11:54. This is what happened:
#>date ; ./alarm ; date Sa 9. Jun 11:52:55 CEST 2007 alarm Sa 9. Jun 11:54:04 CEST 2007
Just as I've expected: alarm() runs independent of any system clocks, it always waits the specified time in seconds. There should be no reason to modify the behavior of the watchdog, since alarm() doesn't care about the calendar clock.
Btw: Even ntpd would step the clock in this case, because clock slew is only used for time offsets of less than 128ms.
And, from the original post:
May 31 20:23:38 localhost vdr: [3413] System Time = Thu May 31 20:23:38 2007 (1180632218) May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007 (1180631977) May 31 20:21:01 localhost vdr: [3405] PANIC: watchdog timer expired - exiting!
The clock was set to 20:19:37, and the watchdog fires at 20:21:01 - 84 seconds later. There must be something different causing the watchdog to expire.
Cheers,
Udo
#include <signal.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h>
static void Watchdog(int signum) { printf("alarm\n"); exit(1); }
int main(int argc, char *argv[]) { if (signal(SIGALRM, Watchdog) == SIG_IGN) signal(SIGALRM, SIG_IGN);
alarm(10); while (true) sleep(1); }
VDR still defaults to start recordings three minutes before scheduled time, right? I wouldn't want to rely my recordings on a clock that is that bad.
That's why I have set it to start ten minutes earlier :)
The worst I had was on a 286, running 40s off per day. Good thing that this is over. Today, I would count one or two minutes per month as worst acceptable.
I agree that the clock is bad, but one of the reasons I started to use VDR was because I had an extra old PC that could be put into use this way. If I have to start buying a lot of new stuff, then I might as well get a STB and complain and demand corrections when it doesn't work. Now I just complain :)
May 31 20:23:38 localhost vdr: [3413] System Time = Thu May 31 20:23:38 2007 (1180632218) May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007 (1180631977) May 31 20:21:01 localhost vdr: [3405] PANIC: watchdog timer expired - exiting!
The clock was set to 20:19:37, and the watchdog fires at 20:21:01 - 84 seconds later. There must be something different causing the watchdog to expire.
OK, this is what I asked in the first mail: "is it the watchdog causing the PANIC?"
And apparently it isn't the watchdog, but the log didn't show anything else that was causing it.
I'll be going away for a month now but when I get back I'll see if I can reproduce the PANIC somehow, just to figure out what is happening.
Josce
ps I really hate using hotmail, the formatting is totally weird...
_________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Managed to get the PANIC again, by doing this:
- set a timer to start 1 hour from now - close vdr - use date to set the clock 5 min forward (with date) - reboot
Can someone else reproduce this?
Josce
Jun 9 22:23:10 localhost vdr: [2220] VDR version 1.4.5 started Jun 9 22:23:10 localhost vdr: [2220] loading plugin: ./PLUGINS/lib/libvdr-dvd.so.1.4.5 Jun 9 22:23:10 localhost vdr: [2220] loading plugin: ./PLUGINS/lib/libvdr-subtitles.so.1.4.5 Jun 9 22:23:10 localhost vdr: [2220] loading plugin: ./PLUGINS/lib/libvdr-dvdselect.so.1.4.5 Jun 9 22:23:10 localhost vdr: [2220] loading /video/setup.conf Jun 9 22:23:10 localhost vdr: [2220] loading /video/sources.conf Jun 9 22:23:10 localhost vdr: [2220] loading /video/channels.conf Jun 9 22:23:10 localhost vdr: [2220] loading /video/timers.conf Jun 9 22:23:10 localhost vdr: [2220] loading /video/commands.conf Jun 9 22:23:10 localhost vdr: [2220] loading /video/svdrphosts.conf Jun 9 22:23:10 localhost vdr: [2220] loading /video/remote.conf Jun 9 22:23:13 localhost vdr: [2220] found 1 video device Jun 9 22:23:13 localhost vdr: [2220] initializing plugin: dvd (0.3.6-b03): turn VDR into an (almost) full featured DVD player Jun 9 22:23:13 localhost vdr: [2220] initializing plugin: subtitles (0.4.0): DVB subtitles decoder Jun 9 22:23:13 localhost vdr: [2220] initializing plugin: dvdselect (0.8): virtual dvd-selector Jun 9 22:23:13 localhost vdr: [2220] ln -nfs '/dev/scd0' '/dev/dvd' 2> /dev/null Jun 9 22:23:13 localhost vdr: [2220] setting primary device to 1 Jun 9 22:23:13 localhost vdr: [2220] SVDRP listening on port 2001 Jun 9 22:23:13 localhost vdr: [2220] setting current skin to "sttng" Jun 9 22:23:13 localhost vdr: [2220] loading /video/themes/sttng-default.theme Jun 9 22:23:14 localhost vdr: [2220] starting plugin: dvd Jun 9 22:23:14 localhost vdr: [2220] starting plugin: subtitles Jun 9 22:23:14 localhost vdr: [2220] loading /video/plugins/subchannels.conf Jun 9 22:23:14 localhost vdr: [2220] starting plugin: dvdselect Jun 9 22:23:14 localhost vdr: [2220] switching to channel 1 Jun 9 22:23:14 localhost vdr: [2220] timer 1 (1 2251-2352 'Actors studio') set to event Sat 09.06.2007 22:55-23:42 'Actors studio' Jun 9 22:23:17 localhost vdr: [2274] System Time = Sat Jun 9 22:23:17 2007 (1181416997) Jun 9 22:23:17 localhost vdr: [2274] Local Time = Sat Jun 9 22:18:00 2007 (1181416680) Jun 9 22:18:01 localhost vdr: [2274] channel 1 (TV1) event Sat 09.06.2007 22:00-22:51 'Karl II - makt och passion (F15)' status 4 Jun 9 22:18:59 localhost vdr: [2220] PANIC: watchdog timer expired - exiting!
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
On Sat, 2007-06-09 at 12:28 +0200, Udo Richter wrote:
And, from the original post:
May 31 20:23:38 localhost vdr: [3413] System Time = Thu May 31 20:23:38 2007 (1180632218) May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007 (1180631977) May 31 20:21:01 localhost vdr: [3405] PANIC: watchdog timer expired - exiting!
Turning clock is always very bad and dangerous thing to do. It can cause lot of other problems too, just to mention incomplete builds, duplicate cron jobs, destroyed logs and files, incomplete backups ...
The clock was set to 20:19:37, and the watchdog fires at 20:21:01 - 84 seconds later. There must be something different causing the watchdog to expire.
It might be even some plugin. All timeouts (cTimeMs, cCondVar, cCondWait) use current wall clock time to set the timeout. Example: cCondWait c; c.Wait(100);
If clock is turned 2 minutes back in middle of this, the code will wait 120100 ms instead of 100ms ... Might cause some quite weird problems. I belive there's no way to change pthread_..._timedwait functions, but cTimeMs can be changed to use monotonic timers instead of gettimeofday (patch attached).
- Petri
Petri Hintukainen phintuka@users.sourceforge.net wrote:
If clock is turned 2 minutes back in middle of this, the code will wait 120100 ms instead of 100ms ... Might cause some quite weird problems. I belive there's no way to change pthread_..._timedwait functions, but cTimeMs can be changed to use monotonic timers instead of gettimeofday (patch attached).
just for the record, i think you have to change the Makefile to include -lrt in the LIBS for the patch to work.
best regards ... clemens
On Sun, 2007-06-10 at 12:31 +0200, Clemens Kirchgatterer wrote:
Petri Hintukainen phintuka@users.sourceforge.net wrote:
If clock is turned 2 minutes back in middle of this, the code will wait 120100 ms instead of 100ms ... Might cause some quite weird problems. I belive there's no way to change pthread_..._timedwait functions, but cTimeMs can be changed to use monotonic timers instead of gettimeofday (patch attached).
just for the record, i think you have to change the Makefile to include -lrt in the LIBS for the patch to work.
That's right, that part was missing from the patch :(
- Petri
Petri Hintukainen wrote:
It might be even some plugin. All timeouts (cTimeMs, cCondVar, cCondWait) use current wall clock time to set the timeout.
Thats not even all: There are 140 references to time(NULL) in VDR, and most of them are used for timeouts between a few seconds and some hours. Even the famous "video data stream broken" (causing an emergency shutdown) can be triggered by a 30-second time step.
Cheers,
Udo
On Sun, 2007-06-10 at 14:59 +0200, Udo Richter wrote:
Petri Hintukainen wrote:
It might be even some plugin. All timeouts (cTimeMs, cCondVar, cCondWait) use current wall clock time to set the timeout.
Thats not even all: There are 140 references to time(NULL) in VDR, and most of them are used for timeouts between a few seconds and some hours. Even the famous "video data stream broken" (causing an emergency shutdown) can be triggered by a 30-second time step.
He :) All places where time(NULL) is used to measure some time interval could easily be changed to use monotonic cTimeMs. But with timers current wall clock time is really required ...
It might be enough to replace most of time(NULL) 's with something like
time_t cTimeMs::Time(void) { return (time_t)(cTimeMs::Now() / 1000); }
Using the cTimeMs timer/trigger mechanism requires some more changes and debugging.
- Petri
On 06/09/07 21:40, Petri Hintukainen wrote:
On Sat, 2007-06-09 at 12:28 +0200, Udo Richter wrote:
And, from the original post:
May 31 20:23:38 localhost vdr: [3413] System Time = Thu May 31 20:23:38 2007 (1180632218) May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007 (1180631977) May 31 20:21:01 localhost vdr: [3405] PANIC: watchdog timer expired - exiting!
Turning clock is always very bad and dangerous thing to do. It can cause lot of other problems too, just to mention incomplete builds, duplicate cron jobs, destroyed logs and files, incomplete backups ...
The clock was set to 20:19:37, and the watchdog fires at 20:21:01 - 84 seconds later. There must be something different causing the watchdog to expire.
It might be even some plugin. All timeouts (cTimeMs, cCondVar, cCondWait) use current wall clock time to set the timeout. Example: cCondWait c; c.Wait(100);
If clock is turned 2 minutes back in middle of this, the code will wait 120100 ms instead of 100ms ... Might cause some quite weird problems. I belive there's no way to change pthread_..._timedwait functions, but cTimeMs can be changed to use monotonic timers instead of gettimeofday (patch attached). ...
I have (finally, sorry for the big delay) adopted this patch (in the attached form) to fix a problem with SVDRP connections when the system time is adjusted.
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. Are there actually systems that have a 1 ms resolution? Or is there some parameter that needs to be adjusted to get a better resolution?
Maybe we should set the limit to, say, 10 ms, so that systems like mine can also benefit from this. After all, the advantage of having a monotonous clock outweighs the courser resolution (typically such timeouts are not below 10 ms).
Klaus
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).
Are there actually systems that have a 1 ms resolution?
Any with HZ=1000, I expect :-)
[snip]
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.
Klaus
On Sonntag, 2. Dezember 2007, Klaus Schmidinger wrote:
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.
Then please do fix it so that it also works with HZ=100, as that is also a valid setting I think VDR should be able to run with.
Matthias
I demand that Klaus Schmidinger may or may not have written...
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.
That says nothing (to me) about how it's configured... :-)
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.
Valid HZ options are 100, 250, 300 and 1000, unless overridden by an arch-specific Kconfig file. (AFAICS, only mips does this, offering 48, 100, 128, 250, 256, 1000 and 1024.)
I have one computer on which I use HZ=100; however, it has no DVB devices.
On 02/12/2007, Darren Salt linux@youmustbejoking.demon.co.uk wrote:
Valid HZ options are 100, 250, 300 and 1000, unless overridden by an arch-specific Kconfig file. (AFAICS, only mips does this, offering 48, 100, 128, 250, 256, 1000 and 1024.)
zen-sources which are a really good option for multimedia desktop offers much more choices than those.
On 12/02/07 16:09, Grégoire FAVRE wrote:
On 02/12/2007, Darren Salt linux@youmustbejoking.demon.co.uk wrote:
Valid HZ options are 100, 250, 300 and 1000, unless overridden by an arch-specific Kconfig file. (AFAICS, only mips does this, offering 48, 100, 128, 250, 256, 1000 and 1024.)
zen-sources which are a really good option for multimedia desktop offers much more choices than those.
Well, I guess then it's probably best to not check this at all.
Klaus
On Sunday 02 December 2007, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
On 12/02/07 14:34, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
I'll make it a 5 ms limit then, to allow default kernels to work.
Valid HZ options are 100, 250, 300 and 1000, unless overridden by an arch-specific Kconfig file. (AFAICS, only mips does this, offering 48, 100, 128, 250, 256, 1000 and 1024.)
Not that I really know much at all about this, but how would this change behave with NOHZ kernels?
Ville Skyttä wrote:
On Sunday 02 December 2007, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
On 12/02/07 14:34, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
I'll make it a 5 ms limit then, to allow default kernels to work.
Valid HZ options are 100, 250, 300 and 1000, unless overridden by an arch-specific Kconfig file. (AFAICS, only mips does this, offering 48, 100, 128, 250, 256, 1000 and 1024.)
Not that I really know much at all about this, but how would this change behave with NOHZ kernels?
Apparently resolution is reported as 1 ns regardless of HZ when NO_HZ is used:
$ ./hz cTimeMs: using monotonic clock (resolution is 1 ns) $ zcat /proc/config.gz | grep "_HZ=" CONFIG_NO_HZ=y CONFIG_HZ=100
Klaus.Schmidinger@cadsoft.de(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?
However, there are some other clock-dependent things in VDR that are not designed to handle larger clock jumps. Usually, clock jumps should be just a few seconds, and only after starting VDR.
You should investigate what causes the clock to jump 4 minutes. If your PC clock is THAT bad, its probably worth dumping the mainboard - you do want recordings in time, do you?
Well if the PC clock was correct all the time I would probably not have to use the set time function :)
Josce
_________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
hi,
Josce Unknown writes:
Well if the PC clock was correct all the time I would probably not have to use the set time function :)
Yes, but typically PC HW clock does not drift so much. You could use hwclock --systohc (and possibly --utc or --localtime) after letting the vdr to set the system clock. I run this as something like (sleep 60;hwclock...)& before the vdr command in the runvdr script.
Since our vdr gets up every day, the system clock is never too much out of the right time.
yours, Jouni
-
Anssi Hannula -
C.Scheeder -
Clemens Kirchgatterer -
Darren Salt -
Grégoire FAVRE -
Josce Unknown -
Jouni Karvo -
Klaus Schmidinger -
Matthias Schwarzott -
Petri Hintukainen -
PLU Dominique -
Udo Richter -
Unknown Unknown
-
UseNet-Posting-Nospam-74308-＠zocki.toppoint.de -
Ville Skyttä