How real-time is java?

[StateMachine]

In a loop, how much can the execution time vary between identical iterations?
Most of all I'd be interested in an Android 3 environment. But any experience you have of java timing fluctuations would be interesting in order to get any idea. Milliseconds? Whole seconds?

Of course, java is not ideal for real time programming, with its garbage collection and thread management. And of course the OS and other applications matter. But can anything be said about what timing precision one can count on anyway? Can I count on doing something within a 1/10 second time window 95% of the time?

Can one ask time in milliseconds in a way to know afterwards when things were done? Or will there be random gaps between execution and a time request too?

What can be done to improve the real-time:ness of java on Android?

Thanks beforehand

[ozzyman]

You can measure nanoseconds in Java.

   long startTime = System.nanoTime();
   // ... the code being measured ...
   long estimatedTime = System.nanoTime() - startTime;

In case you don't know, 1/10th of a second = 100 milliseconds = 100,000,000 nanoseconds (yes, 100 million nanoseconds).

It may be true that other languages might be slightly faster than java, but what is it you're trying to achieve here?

Try it yourself and see how long it takes to execute the code you want to do.

[StateMachine]

If 1/10th of a second is ridiculously long time according to you, then that's a bit reassuring!

But, "nanotime"? Is that really reliable to the nanosecond? That's down to the GHz. How ever could some java code figure out what's being done by a CPU down to that level?? Maybe it's spent the last few of'em shifting some cache memory from here to there, and God knows if that particular java code asking what time it is, has anything to do with that.

On an Android mobile phone with a CPU of about 1 GHz, how big could the *unevenness* of the execution of operations be? I'm not interested in average speed, but in time measurement errors caused by other java applications, JVM, OS and who knows what. If 100 ms is ridiculously out of the way, then could I safely rely on a precision of 1 ms?

Edit:
Oh, you of course mean that there's a clock to call in order to find out!? I really hope it's as reliable as it pretends to be.

[ozzyman]

Its an estimation but you can gather that if you can get estimates of 150 nanoseconds for small bits of code execution then you're still safe if your accuracy is to the nearest 100 milliseconds.

When you say rely what exactly are you trying to achieve?

[StateMachine]

I'd like to be able to take the time between photographs with good precision. Or, if I cannot control the timing, then at least afterwards know at what time the shutters opened. And I'm afraid that taking a picture is such a big and complex process, for the OS and the hardware, that a java application would be clueless as to when it actually happened. Won't there be a que or two between a shootNow() method is called, and photons actually register on the light detector? And then again an unknown time interval until the java application is notified that the image data is now available (maybe even after having been compressed to JPEG by the API, the OS or some hardware chip, a compressing process the duration of which depends on what the motive happens to looks like).

[ozzyman]

Taking photographs is a pretty heavy task, my android phone doesn't let me take photographs if my battery level is below 15%.

Most cameras can't take more than 30 photographs per second (to make a video). 1/30 seconds = 33 milliseconds.

Still photographs are usually taken in a much higher resolution and so you can take much less in a second. Probably less than 10 with a continuous shooting mode on high quality.

So I don't think you need to worry about 1 millisecond.

[StateMachine]

Oh, I don't need to take them that frequently. But I would like to know the time between them. If its 2.15 or 2.25 seconds between them would matter to me. I wonder if java is a no go then?

[ozzyman]

No its completely fit for your purpose. No worries about that.

[StateMachine]

That'd be great!
Even down to 1/100th second?
Even on a buzy slow mobile device?

[kjkrum]

It seems like the only way you'll ever know for sure is to test it. Set up an experiment where you photograph something moving at a known speed at set intervals. Stepper motors, for example, can be made to rotate at precise speeds... as precise as the microcontroller driving them, anyway. Set up a spinning color wheel or something and try to make your software photograph it at some multiple of its rotation time.

[j2me64]

That'd be great!
Even down to 1/100th second?
Even on a buzy slow mobile device?

Test it and tell if the results are or

[JosAH]

It all depends on the processor speed and how fast the OS responds to requests (to read the clock). I once had an old HP PDA and I put an old version of Java on it ('Personal Profile') The clock had a granularity of 1 second, no matter what I did.

kind regards,

Jos

p.s. That little thing is long dead ...

[quad64bit]

FYI, java is not a 'real-time' language and makes absolutely no guarantees on runtime performance. It is completely at the mercy of the OS it runs on. That being said, with careful control of garbage collection (what little control you have), careful resource management, and a minimum of variables on the host system, you can predict times with relative accuracy. Java supports nano-second timing, however, 99% of the stuff I have done involving timing falls into the ms range.

You can use lots of techniques for time management - You can simply record System.currentTimeMillis() values to calculate deltas, and you can use that info to calculate frame rates, delays, etc...

For my apps, I rely on a system of hard coded deltas which I compare to the current time elapsed. System.currentTimeMillis() is accurate enough for most things save perhaps scientific calculation. System.nanoTime() does have a higher degree of accuracy, but in my experience it isn't really nanosecond level, or at least there isn't much useful work that is done in a nanosecond for it to matter much. I am primarily concerned with animation, where ms is way more than enough to work with 60ths of a second frame rates, or 120hz logic rates, etc...