Re: [pygame] BUG: pygame.time tick()?

[James Paige <Bob@xxxxxxxxxxxxxxxxxxx>]

If it turns out to be impossible to make delay() detect backwards jumps 
in time, a possible workaround for the specific problem of ntpdate is to 
use ntpdate's -B option, which causes the clock to be "slewed" in a way 
that might avoid this problem.

---
James Paige

On Fri, Jun 27, 2008 at 01:19:08PM -0500, Charlie Nolan wrote:
> clock.tick goes through SDL_Delay, so the relevant source isn't in
> pygame, but I'm guessing things look roughly like this:
> 
> def delay(ms):
>     until = time.time() + ms
>     sleep_time = ms
>     while sleep_time > 0:
>         time.sleep(sleep_time)
>         sleep_time = until - time.time()
> 
> So what's happening is this:
> 1. delay is called and goes to sleep for 1/30th of a second.
> 2. clock is set back X hours.
> 3. delay wakes up, goes back to sleep for X hours.
> 4. clock is set forward X hours.
> 5. delay will still be sleeping for X hours, because it doesn't see
> the new time.
> 
> Since the loop above is more or less the Right Way to do things, the
> answer to your issue is contained in an old joke:
> "Doc, you gotta help me."
> "What's the matter?"
> "My elbow hurts terribly when I do this."  *demonstrates*
> "Well, don't do that!"
> 
> -FM
> 
> 
> On 6/27/08, John Leach <john.leach@xxxxxxxxxxxxx> wrote:
> > Hi all,
> >
> > Could anyone comment on this problem with the otherwise fantastic
> > pygame.
> >
> > pygame 1.8.0
> > OS Fedora 8 Linux 32-bit
> > python 2.5.1
> >
> > Code essentials:-
> >
> > clock = pygame.time.Clock()
> > while 1:
> >   clock.tick(30)
> >   # various sprite and text blits
> >   pygame.display.flip()
> >
> > This code runs really well and looks great on my test systems (thanks
> > René), however when I transferred to a couple of new computers the
> > program has been hanging. All the moving sprites, moving text etc freeze
> > on the screen after a period of time.
> >
> > I could ssh into the box and everything looked ok. The problem looked to
> > be that my pygame was hanging somewhere.
> >
> > I noticed the hangs were occurring exactly on the hour and tracked the
> > problem to the fact that every hour these machines call ntpdate to set
> > the system clock.
> >
> > I ssh'ed into a running computer and was able to reproduce the problem
> > by running ntpdate manually. The program froze at exactly the time that
> > I ran ntpdate.
> >
> > For these machines, the BIOS clock was set to approx 2 hours behind the
> > current local time and the local time zone is 10 hours in advance of
> > UTC. Linux is configured for UTC.
> >
> > So my analysis of the problem is as follows:-
> >
> > ntpdate was changing the time by approximately 8 hours - quite a large
> > change. And I suspect that the
> > clock.tick(30)
> > statement is hanging at that point.
> > As I understand the function of clock.tick() it is to slow down the
> > processing to match the frame rate specified. So clock.tick() will have
> > a delay loop in it while it waits for the next frame interval to come
> > around. So it seems likely that the program would have frozen for 8
> > hours then come back to life.
> > (however I semi-tested this by changing the time back into the future
> > via ntpdate and the program did not come back into action again).
> >
> > The time module is in C which is not a language I know so I have not
> > been able to diagnose the problem further.
> >
> > Workarounds: for anyone reading this at a later date and having this
> > problem, the possible workarounds I can think of are:-
> > 1) setting the UTC date and time correctly in the bios first up
> > 2) ???setting the date and time using ntpdate on first installation then
> > rebooting (to set the hardware clock)
> > 3) ???setting the date and time using ntpdate on first installation and
> > then using hwclock to write this time back to the BIOS
> > 4) ???Having done one of the above 3, using ntpd instead of ntpdate to
> > ensure the time stays correct without major sudden changes.
> >
> > The problem does not appear to happen now that I have corrected the
> > times (or has not happened since I corrected the times on those
> > computers).
> >
> > It is also worth pointing out that the problem did not occur every time
> > ntpdate was run with a large time change; I put that down to the fact
> > that if ntpdate was run when the program was not in clock.tick() then it
> > was ok, but if it occurred when inside clock.tick() then the problem
> > could occur. Possibly the reverse could be true.
> >
> > Does this sound likely?
> >
> > Regards
> > John Leach
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >