[android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
just a little followup.. thanks again Robert for encouraging me to use nanoclock. I eventually got around to the conversion (I had been invoking System.currentMillis in a thousand individual locations, of course :-) Anyway clock sync is better than ever, whether I am on Wifi/3gs or lagging my pooter out with four emulators. - Dan On Mar 11, 12:23 am, Robert Green rbgrn@gmail.com wrote: FYI - Good that you're doing it that way. I have to recommend switching to nanoTime, though. I've witnessed multi-second time updates (from the system, not from me) while playing my games and it's not pretty. I've switched everything to nanoTime / 100 since then (which gives milliseconds) and all seems to be well. On Mar 10, 10:01 pm, 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 theemulatorto 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() / 100; 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: =- Hide quoted text - - Show quoted text - -- 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 To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
Fwiw, we generally use SystemClock.uptimeMillis() in the platform. This is monotonic and should not jump. It does not increment when the CPU is not running, but typically this is actually fine or even good behavior. (For example, it is used to time messages in handlers; if you post a delayed message to the handler, that delay will be longer if the CPU is stopped. This is actually a good thing, since it means when the CPU wakes up after being stopped for an hour or whatever, you don't suddenly have a bunch if spurious stuff to do.) On Thu, Mar 11, 2010 at 12:23 AM, Robert Green rbgrn@gmail.com wrote: FYI - Good that you're doing it that way. I have to recommend switching to nanoTime, though. I've witnessed multi-second time updates (from the system, not from me) while playing my games and it's not pretty. I've switched everything to nanoTime / 100 since then (which gives milliseconds) and all seems to be well. On Mar 10, 10:01 pm, 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() / 100; 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com 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 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 To unsubscribe
[android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
Dianne, I don't know why but I found that my games were jittery using SystemClock.uptimeMillis(). It's as if there was a little inconsistency and when doing time-interpolated movements, it shows. I've never run a test comparing the output of nanoclock vs uptime so I have no empirical evidence, but that's what I eyeballed. I switched to nanoclock and everything goes back to looking smooth. Strange. On Mar 29, 9:07 pm, Dianne Hackborn hack...@android.com wrote: Fwiw, we generally use SystemClock.uptimeMillis() in the platform. This is monotonic and should not jump. It does not increment when the CPU is not running, but typically this is actually fine or even good behavior. (For example, it is used to time messages in handlers; if you post a delayed message to the handler, that delay will be longer if the CPU is stopped. This is actually a good thing, since it means when the CPU wakes up after being stopped for an hour or whatever, you don't suddenly have a bunch if spurious stuff to do.) On Thu, Mar 11, 2010 at 12:23 AM, Robert Green rbgrn@gmail.com wrote: FYI - Good that you're doing it that way. I have to recommend switching to nanoTime, though. I've witnessed multi-second time updates (from the system, not from me) while playing my games and it's not pretty. I've switched everything to nanoTime / 100 since then (which gives milliseconds) and all seems to be well. On Mar 10, 10:01 pm, 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() / 100; 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.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide
[android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
I admit I have pretty much given up on all the android string formatting, as just being too painfully slow to use during the game itself. I'm actually not using many views any more either, though that's probably just an overreaction on my part. I basically have one view (once the game starts) and do all the rendering/interacting/ stroke analysis myself. So I have reinvented quite a few wheels, and I do feel bad about it, but saving 5ms here and there is nothing to sneeze at when you have a 50ms budget. I'm addicted to drawBitmap with matrix though. Robert, thanks for the motivation to switch to nano. I have added it to the list of things-to-actually-do. On Mar 10, 11:35 pm, Kaj Bjurman kaj.bjur...@gmail.com wrote: 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. -- 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
[android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
at the risk of answering my own question (with the to-be-expected accuracy level associated with that), it appears that if I * shut down eclipse * open two CMD windows * launch the emulators from command line that I get much better peformance (5x better?), less 'time-slice- theft' (top window still runs faster, but back window no longer comes virtually to a halt), and the currentTimeMillis() seems to track much more reliably between the two instances. if I do it right, it is even slightly less tedious to start up than launching from within eclipse, though I admit to being addicted to having eclipse actually install the apks :-) On Mar 10, 5:36 pm, Samsyn d...@synthetic-reality.com wrote: so... I am testing my multiplayer game by running several instances of the emulator (which is, sadly, extremely slow and dis-satisfying). I depend on a little trick using currentTimeMillis() to keep a synchronized clock between the players (but NOT the absolute value of currentTimeMillis() since no two phones are probably set exactly the same) Anyway, I *do* naively assume that two emulators, running on the same PC would return near identical values for calls to currentTimeMillis(), and what I find is that they start off the same, but pull rapidly apart. Which makes me think the underlying implementation of currentTimeMillis() in the emulator is not at all based on the host PC's calendar, and rquires the emulator to get enough Windows compute cycles to be anything close to accurate. (and one emulator is always running at a lower priority to the other, depending on which one is on top) If this is just an artifact of the emulator, then I can deal with it, but if it implies I have a fundamental misunderstanding of currentTimeMillis(), then that would be something i need to deal with. Part two of the question is: any way I can speed up the emulator? When I run two, are they sharing one of my cores? Can I split them onto separate cores? -- 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
[android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
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() / 100; 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: so... I am testing my multiplayer game by running several instances of the emulator (which is, sadly, extremely slow and dis-satisfying). I depend on a little trick using currentTimeMillis() to keep a synchronized clock between the players (but NOT the absolute value of currentTimeMillis() since no two phones are probably set exactly the same) Anyway, I *do* naively assume that two emulators, running on the same PC would return near identical values for calls to currentTimeMillis(), and what I find is that they start off the same, but pull rapidly apart. Which makes me think the underlying implementation of currentTimeMillis() in the emulator is not at all based on the host PC's calendar, and rquires the emulator to get enough Windows compute cycles to be anything close to accurate. (and one emulator is always running at a lower priority to the other, depending on which one is on top) If this is just an artifact of the emulator, then I can deal with it, but if it implies I have a fundamental misunderstanding of currentTimeMillis(), then that would be something i need to deal with. Part two of the question is: any way I can speed up the emulator? When I run two, are they sharing one of my cores? Can I split them onto separate cores? -- 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
[android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
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() / 100; 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
[android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
FYI - Good that you're doing it that way. I have to recommend switching to nanoTime, though. I've witnessed multi-second time updates (from the system, not from me) while playing my games and it's not pretty. I've switched everything to nanoTime / 100 since then (which gives milliseconds) and all seems to be well. On Mar 10, 10:01 pm, 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() / 100; 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
[android-developers] Re: currentTimeMillis() doesnt match on two concurrent emulators
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() / 100; 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
