Emulator clock is not emulated?

[Lacinato]

Hi everyone -

"New guy" question, here... I've been googl'ing and stack-overflow'ing around trying to dig up the answer to this but I can't seem to...

The system clock in the android emulator (e.g. SystemClock.uptimeMillis()) -- it appears to be synced to the actual host computer hardware
clock, as opposed to being emulated... right? It would seem necessary if the emulator were to be playing A/V streams or doing anything else that
depended on an accurate sense of time (games, transition effects, etc), but it's apparently a hard question to definitively answer. All my tests
indicate that this is the case. Any thoughts to the contrary?

Thanks!
-Casey

--
Lacinato
http://lacinato.com

[Mark Conover]

Good question.   Haven't seen that documented anywhere.  So, how about a test:   Configure your host computer to a bogus time (after first shutting down any emulators and disabling any host ntp setting).  Then launch an emulation.   I'd logcat at the get go in case interesting relevant messages appear.

Have fun,

Mark

[Lacinato]

Thanks for the idea, Mark. I believe that the "time" is independent of the host; meaning that the date/time indicated in emulator world is not
coupled to the host computer, but that the results of System.currentTimeMillis() and SystemClock.uptimeMillis() increase in time with the real
clock, so I'm not sure that test would answer my question exactly.

The tests I did run involved this kind of simple stuff:

long start = SystemClock.uptimeMillis();
Log.d("blah", "start");
while (SystemClock.uptimeMillis() < start + 10000)
{
// do some work-intensive stuff here
}
Log.d("blah", "finish");

...regardless of what I did in the intervening 10 seconds (inside the code loop and/or intentionally using my computer to do other stuff to load
the CPU) the thread always wakes up exactly 10 seconds after it starts (+10ms, overhead I assume), judging by both the LogCat timestamps and a
stopwatch, which says to me that a loaded host CPU doesn't dilate the sense of time in the emulator at all, as would be expected.

I just realized that I didn't post this in the Android google group yet... Maybe I'll try that, but I think I may have my answer.

The emulator takes 40-60% of my CPU when totally idle, and 100% when it's doing anything, so the discrepancy between real time and emulator time
is pretty serious, which is a bummer for a guy working on a real-time app without a phone. :-)

Thanks,
-Casey

Lacinato
http://lacinato.com

On 04/25/2011 09:55 PM, Mark Conover wrote:
> Good question. Haven't seen that documented anywhere. So, how about a test: Configure your host computer to a bogus time (after first
> shutting down any emulators and disabling any host ntp setting). Then launch an emulation. I'd logcat at the get go in case interesting
> relevant messages appear.
>
> Have fun,
>
> Mark
>

[Lacinato]

By "wakes up" I meant something like "reports back"... not Thread.sleep()'ing in that test... -c

[Lacinato]

I believe that the option I want (?) is:

$ emulator -avd my_avd -qemu -clock vm

But that may just have to do with setting the time when starting the VM, which QEMU apparently does do. Regardless, the Android QEMU seems to
lack the "vm" clock:

$ emulator_real -avd my_avd -qemu -clock ?
Available alarm timers, in order of precedence:
unix

...Signing off on this issue for now, thanks for listening. :-)

-c

[Iain (IT) Davidson]

FYI,

   I also seem to remember reading some documentation about Android timing.  Some time functions are more accurate than others (orders of accuracy?).  Will run into some issues, if you use one 'system' of timing, and mix them with others.

Unfortunately, I don't remember which functions.  But I ran down a timing issue myself awhile back ago, and discovered that I was 'mixing timing systems'.  Once I figured that out, I picked which system to use. . . and stuck with it.

:)

-Iain

[Lacinato]

Hi - are you talking about the differences between System.currentTimeMillis(), System.nanoTime(), SystemClock.uptimeMillis(), etc, or some other
issue? I think I have the various functions understood...

Thanks!
-c

On 04/26/2011 12:05 AM, Iain (IT) Davidson wrote:
> FYI,
> I also seem to remember reading some documentation about Android timing. Some time functions are more accurate than others (orders of
> accuracy?). Will run into some issues, if you use one 'system' of timing, and mix them with others.
>
> Unfortunately, I don't remember which functions. But I ran down a timing issue myself awhile back ago, and discovered that I was 'mixing timing
> systems'. Once I figured that out, I picked which system to use. . . and stuck with it.
>
> :)
>
> -Iain
>