[vdr] Re: Broken stream detection (again)

[Peter Dittmann <peter.dittmann@freenet.de>]

On Thu, 12 Jun 2003, you wrote:
> [Peter, please fix your client to wrap lines to a length of 76 chars max.
> and please try to use a different mail client that keeps the
> Reference-Headers in the mail so that the threading information doesn't
> get lost]
 Impossible if I use my work PC over daytime (IT policy ;-(( ).
(I knew somebody would jump to this *g* )
 I've allready used a plain online client with the result that the posting was
completely crippled/encrypted; so a realy bad idea ;-((
 
> >> How do you set your system clock? Do you use the VDR feature to set the
> >> time? Do you use rdate or ntpdate?
> > 
> >> Normally, the system clock *does not* jump. It's always a user process
> >> that forces a jump, e.g. rdate updateing the clock.
> >> This is considered bad as it may break different things, like drivers or
> >> daemons (as you noticed). Best practice is to use rdate/ntpdate only once
> >> at system boot time and then run ntpd to get a smoothly adjusted clock.
> 
> > I neighter use rdate or ntpdate.
> > It's just VDR which may correct the system time (I don't know if Klaus uses rdate/ntpdate or just an API call).
> > Anyway I don't expect VDR to add 70min to the system time just for fun.
> > I have no log entry that VDR was setting it to the scrappy time but you always see it's VDR setting the time back to were it belong.
> > So the big question is who's crewing up the system time in first place?
> > The installation is a freshly installed Suse 8.1. Except VDR nowbody else should be set up to do updates to system time.
> > No external services are running. So there is absolutely no source for system time updates other than VDR.
> 
> So I assume you told VDR to set the system time from a transponder?

Yes, but I disabled this today evening and the glitches are still there. They
are more or less precize 72min +/- 30sec (to precize to be concidence !)
And they correct automaticly in the next log entry without VDR now kicking in
(with enabled time setting VDR was kicking in to fix the system time).
If you read carefully: according log it was not VDR that caused this offset,
but VDR was fixing it !
I'm absolutely shure no other service is running that set/tweak
system time on this system.
To me this locks like a race condition, e.g. checking time at a critical time
window that caused some temporary overflow.
(by the way 2^32usec are 71min 34,9673sec and timer.c counts usec's;
strange coincidence ;-) )

> 
> > I've also noticed a shifted CMOS clock on my system when I rebooted after several days/weeks of the system being up and running.
> 
> This might be just that you configured your OS wrong. If you run Linux
> you should set the CMOS clock to UTC (formerly known as GMT) and tell
> your Linux that the CMOS clock is running in UTC. Often Linux
> distributions sync the cmos clock with the current system time on
> shutdown. If you configured your system time wrong, there might be a jump
> of one or more hours after a reboot, depending on your timezone and
> daylight saving.
Might be, but it's not just full hours.

> 
> > I was just pointing towards there are several people complaining about LIRC time problems, some complain about glitches in recordings (which I have now as of timers being continously stopped and restarted), a lot are complaining about emergency exits.
> 
> These seem to be different problems, but if your time jumps (for whatever
> reason), than all kind of things may break - not only VDR.

Shure ??!
The LIRC problem (IEEE: your clock just jumped backward) seems to be a
problem with do_fast_gettimeoffset() in time.c. I have spend a few time on this
with the old setup using Suse7.1/2.4.0; and I have counted at least 3..4
postings over the last 6 month that mentioned this.
 
The problems I still have with timers starting/stopping at random produces the
glitches reported by different persons in the list. The log entries are only
visible when VDR is told to do full logging (which is not the default !). So a
lot of people might not even realize this but complain then about the
video/audio glitches during playback.

> 
> > If you take time looking over the kernel files for timer, you realize a lot of constrains and fixes for different hardware (CPU types). Maybe not everything is working cleanly on all the boards.
> > I remember even finding some warnings about not monotonic time events in those kernel files.
> 
> It runs for million users out there without a problem, so it must either
> be a configuration error on your side or your hardware is badly broken.
> 

No reason to not still contain spurious bugs ;-)
Just take the time going over kernel/arch/i386/time.c
It's stuffed with conditional compilation and annotated risk items and
workarounds (looks like amost all harware variants have it own flaws).

I doubt that a non expert can realy set this up foolproof. There is way to much
hardware setup for the average user.
And a of-the-shelf kernel does not detect this during runtime. You need to
compile it to your special chipset (see TSC and Neptun remarks in time.c)
-> and I'm (still) using the of-the-shelf kernel from Suse.

The point here is out of the millions user only a limited bunch (<1%) does real
time operations with linux. 
For a typical system it's not critical if the time is for a few miliseconds
incorrect or have race conditions. This will not be realised by the majority of
the users and programs running on linux. 
And if it does you have a wrong time stamp of a written file 
(not a big deal ;-))
It's only the real time users that might realize if the time jumps suddenly.

And maybe Klaus is having a rock solid board and doesn't need to struggle with
this... ;-))

kind regards	Peter

> Cheers,
> Juri
> 
> 
P.S. From my daily work I know most comercial components behave slidly different
from their specs.
I'm also handling commercial player source code at Philips (e.g DVD player code
>500k lines of code) and I should recognize a race condition when I see one
;-))



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.