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 <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
