|
Rockbox mail archiveSubject: Re: X11 simulator clock runs too fastRe: X11 simulator clock runs too fast
From: c s <rb_dev_at_yahoo.com>
Date: Fri, 7 Mar 2003 02:25:06 -0800 (PST) --- Daniel Stenberg <daniel_at_haxx.se> 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()? --- Craig __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/Received on 2003-03-07 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |