Thanks! Doing it in native might be a good idea. 1. Will increasing the thread priority improve accuracy (starving other threads in the meanwhile of course)? 2. The operation I'm doing involves network activity - UDP\TCP packet sending. Is there good native support for networking that is device independent (like the normal libc, libz)? Or maybe I should ask this in the NDK group?
On Jul 5, 10:08 pm, Dianne Hackborn <[email protected]> wrote: > You are doomed if you just want to be able to schedule exactly 80ms every > time so that you add it all up after 1000 times and you get 80 seconds. > > At the very least, you should schedule your events so that even if there is > some jitter in individual timings they add up correctly -- that is start at > the current time, then schedule each next event for a successive 80ms from > that base time, regardless of when the previous event actually fired. > > At this point, then, the only question is how much jitter between events you > will find acceptable. As Richard said, some big events can cause a fair > amount of jitter, in particular GCs. The platform is designed to avoid > thrashing through objects and thus not cause GCs, so if you are likewise > careful you may be able to do things so that GCs don't happen enough to be > an issue. For perspective: on low-end hardware, a GC can take on the order > of 100ms; on higher-end devices like the Droid it is more like 30ms. > > If that is still not sufficient, you may want to consider dropping down to > native code and doing the timing in a separate native thread (which thus > won't be paused by GCs). Of course you still won't have 100% accurate 80ms > every time because there will still be other processes wanting to run at > times, though the jitter will be significantly smaller (as long as your > process is not in the background scheduling group). > > > > > > On Mon, Jul 5, 2010 at 7:30 AM, Omer Gilad <[email protected]> wrote: > > Hello, > > Does anyone know of a precise way of measuring 80 milliseconds for > > scheduling purposes? > > Thread.sleep() and SystemClock.sleep() don't seem accurate enough. > > > Purpose - I want to schedule a certain event to happen in an exact > > interval of 80 milliseconds and I don't want the time to skew > > (scheduling 1000 such events must take 80 seconds in total). > > > Thanks > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%2Bunsubs > > [email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
