Have you checked all entried in logcat to see if you can see anything odd? I had e.g. a loop where each iteration did something like:
Log.i(TAG, "Forecast expires at " + aJavaDateInstanceRepresentingExpirationDateTime); Each execution of that log statement took about 1-2 seconds since date.toString() caused a resource bundle to be loaded by Android OS. I can't understand why it is implemented like that, and isn't cached, but I wasted about 10 seconds there. On 11 mar, 05:01, Samsyn <d...@synthetic-reality.com> wrote: > Thanks, Robert! > > yes, don't worry, I wasn't doing that. :-) > > Basically the server has the master time, each client has a dynamic > ping value to the server, which is also shared with the other clients > for suitable adjustments. at key moments a client notes the local > currentMillis() value matching an important server time value, > computes a delta which it can then use to move between currentMillis > and server time as needed (until the next Important Event freshens the > sync). > > Important Events occur frequently enough to keep the clients > reasonably well synched, so long as I can depend on currentMillis to > actually move forward in real time (i.e. 500 ms from now, I need it to > be roughly 500 counts higher). Though a little jitter doesn't bother > me, seeing it jump 10 SECONDS in a 2 second period was causing me > alarm. > > I will, of course, fail if the client changes their clock setting in > mid-game. And I suppose the phone itself could initiate such a change > based on some signal from the provider, but I tell myself it will only > fail 'a little' in that case (assuming the hardware is not horribly > defective), so I choose not to worry about that. (knowing that I > COULD use the nanotime to remove that sensitivity, but something makes > me prefer currentMillis right now... some unproven suspicion that it > is a cheaper computation.) > > And I assume what was happening before was that running multiple > emulators under eclipse was starving them of cpu to such a degree that > an internal emulation of the phone clock was missing some important > polled event. I can't decide if I think that's cool or not. Would it > be cheating for the emulator to just read the host hardware clock?... > I guess so. So instead it probably reads a simulation of the > nanoclock, which turns out to be unreliable in a low cpu cycle > environment. > > And manually running emulators in separate CMD windows seems to help > it take advantage of the host's multiple cores. Which I guess would > be asking Eclipse a lot to do, given that it is also giving me all > those nice debug hooks :-) I shouldn't be so demanding. I love you, > Eclipse, I really do, except when you crash or that time you deleted > every source file in my project with nary a warning. > > Thanks again! > > - Dan > > On Mar 10, 5:53 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > > > Samsyn, > > > For multiplayer synchronization, you absolutely can not count on the > > current time of either device. Here's one way to handle it: > > > Both host and client use System.nanoTime() / 1000000; That gives you > > a fairly accurate counter to use. > > Host sends snapshots with their current time. Client adapts the > > host's time for interpolation by attempting to detect ping and use it > > as a skew. > > > On Mar 10, 7:36 pm, Samsyn <d...@synthetic-reality.com> wrote: > > = -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
