dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: X11 simulator clock runs too fast

Re: X11 simulator clock runs too fast

From: c s <>
Date: Fri, 7 Mar 2003 02:25:06 -0800 (PST)

--- Daniel Stenberg <> wrote:
> 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?

It seems like that approach would cause the tick to
advance in quick bursts until it came up against the
one second boundary and then stop until the boundary
advanced to the next second. That's not a problem if
you are doing TIME_AFTER waits for >1 second periods
because as you said on average the tick will be
correct but for fraction of a second TIME_AFTER waits
it would either be too fast or too slow depending if
you caught it where the tick was racing to the
boundary or waiting for the boundary to advance.

I liked your earlier suggestion of just doing the
shortest wait that your system is capable of and then
checking how much time has elapsed and increment
current_tick accordingly. This would require a library
call to get a high resolution clock like
clock_gettime(). Is there any reason that we would
want to avoid using clock_gettime()?

Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
Received on 2003-03-07

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy