Rockbox mail archiveSubject: Re: X11 simulator clock runs too fast
Re: X11 simulator clock runs too fast
From: Daniel Stenberg <daniel_at_haxx.se>
Date: Fri, 7 Mar 2003 09:22:46 +0100 (CET)
On Thu, 6 Mar 2003, c s wrote:
> That being said, it is still desirable to try to achieve a somewhat
> accurate tick in the simulator if we can do it without making the simulator
> code non-portable. Currently it runs 10 times too fast, on the system I run
> on, so all the places in the rockbox code that check on an elapsed time by
> doing "TIME_AFTER(current_tick, xxx)" are off by a factor of 10.
Yeah, that's a pretty big difference.
> When I change the increment value in x11_sleep form 5 to 'tics', then
> current_tick runs about 3 times too fast (because of the problem that I
> discussed earlier where multiple threads can be in a sleep call and all
> will be incrementing current_tick).
> The best quick fix seems to be to change the increment value in x11_sleep
> from 5 to 1. This works fairly well because no matter what rockbox is
> doing, there is always a thread doing constant calls to
> button_get_w_timeout which does multiple calls of sleep(1) to do its
Right, that would be a quick somewhat working way. But what about doing it
like this: we add an extra thread that only updates a global max_tick
variable every second (or so), and then the x11_sleep() makes sure to never
increase the 'current_tick' to a value that is larger than to the max_tick
value. Then we'll get a tick counter that moves EXACTLY as it should in
average over many seconds. Ok, it won't be moving with a constant rate, but I
don't think that'll be a problem...
Oh, and when max_tick is set, it must also make sure that current_tick is no
less than (max_tick - HZ). In fact, it could be set to max_tick - HZ, as it
shouldn't be larger either! :-)
Comments on this approach?
-- Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/Received on 2003-03-07
Page was last modified "Sat May 23 08:12:40 2020" The Rockbox Crew