So after some quick tests, it's apparent that switching out time.monotonic() with either time.clock() or time.time() completely fixes the issue (so the framerate is always between 49~50). For my application, I can probably subclass the eventloop and switch out the timer implementation, but ideally, this should be fixed upstream somehow. I never had this issue with Twisted, even though I think Twisted uses time.time() with some heuristics to detect time drift and similar issues. Personally, I've always found a combination of timeGetTime() and timeBeginPeriod(1) to yield a very stable timer on Windows (especially for games), but perhaps you have greater insight into the issue.
Thanks for the help! Is there any chance this will be fixed in an upcoming asyncio release? Mathias Den lørdag den 17. maj 2014 06.31.18 UTC+2 skrev Guido van Rossum: > > This could well be timer granularity on Windows; this has been a big > problem for the unittests too. Could you try with a different timer? It > should be easy to change the timer function. > > On Friday, May 16, 2014, Mathias Kærlev <[email protected] <javascript:>> > wrote: > >> Hi everyone >> >> I'm currently porting some code from Python 2.7 with Twisted to Python >> 3.4 with asyncio. So far, it's been a pleasant experience. >> However, my application in question is a game server which needs to run a >> 50FPS update loop to simulate the game world. >> When running multiple update loops, I start to get some very unstable >> behavior, where the actual delay between a call_later call and the time it >> fires wobbles between the specified delay and half the delay. >> >> Please see the following example: >> http://bpaste.net/show/Cxn0jxqufnvNk7qL8MnJ/ >> In the example, I run two update loops: one on 50FPS, and one on 100FPS. >> I only monitor the update loop running at 50 FPS. >> Yet, on Windows 7, I get the following output: >> http://bpaste.net/show/XKp4LtKpEsXWxacZjQlc/ >> The framerate is very wobbly, going between ~100 FPS and ~50 FPS (the 100 >> FPS LoopingCall is not being logged, of course). >> >> Is this a bug in my LoopingCall class, or is it a problem with the >> eventloop timer granularity? >> >> This is using the asyncio release found in stdlib on Python 3.4, by the >> way. >> >> Thanks for the help! >> >> > > -- > --Guido van Rossum (on iPad) >
