Android :: CurrentTimeMillis Doesn't Match On Two Concurrent Emulators

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?