Thread loop cycle time

[wanwan]

I'm trying to measure the average cycle time for a loop in a thread
similar to this one:

public void run() {
while (true){
[do something]
Thread.sleep(1000);
}
}

I took the measurements at the beginning of the loop 200 times and
found an average of 996ms. How can it be possible!

I need to find out the time for each cycle so to find out how much time
I need the thread to sleep.

Can anyone comment on my odd measurements?

 

[Gordon Beaton]

I took the measurements at the beginning of the loop 200 times and
found an average of 996ms. How can it be possible!

I need to find out the time for each cycle so to find out how much
time I need the thread to sleep.

If you want your loop times to be accurate, you need to implement a
PLL:

boolean done = false;
long now = System.currentTimeMillis();
long next = now;
long interval = 10; // delay, in milliseconds

while (!done) {
// do your stuff here...

// sleep until next event is due
next += interval;
while (next > ((now = System.currentTimeMillis()))) {
try {
Thread.sleep(next - now);
}
catch (InterruptedException e) {}
}
}

Just make sure "your stuff" needs less time than the interval you
specify.

/gordon

 

[wanwan]

but I don't think System.currentTimeMillis is accurate though. Same
number shows for up to 4 consecutive loops

 

[ronybaryo]

Hi,

This is because the cpu is very fast and not even one msec passed since
last call.

And about your first topic the sleep is not per msec reliable it can be
~10 msec more or less so its possible to sleep(1000) and get 996
average.

Roni

 

[Gordon Beaton]

but I don't think System.currentTimeMillis is accurate though. Same
number shows for up to 4 consecutive loops

Realize that System.currentTimeMillis() is not accurate to 1 ms on all
systems. Even on systems where it is, you will get the same value
multiple times if you call it again within 1 ms. What else would you
expect?

In the code I posted, individual passes through the loop will jitter
if System.currentTimeMillis() not as accurate as you want, and this is
unavoidable. However the long term error is zero because the short
term errors on each pass do not accumulate, and variations in the
"your stuff" part of the loop are compensated for.

/gordon

 

[Thomas Hawtin]

Realize that System.currentTimeMillis() is not accurate to 1 ms on all
systems. Even on systems where it is, you will get the same value
multiple times if you call it again within 1 ms. What else would you
expect?

System.nanoTime should be better (from 1.5). It theoretically isn't
affected by changing the system time either.

In the code I posted, individual passes through the loop will jitter
if System.currentTimeMillis() not as accurate as you want, and this is
unavoidable. However the long term error is zero because the short
term errors on each pass do not accumulate, and variations in the
"your stuff" part of the loop are compensated for.

On average when you call System.currentTimeMillis, Thread.sleep or
anything else, you will be halfway between increments. So if you wait
until it next increments, that will on average be half the period of an
increment. Therefore, you shouldn't expect sleeps to average a round time.

Tom Hawtin

 

[Roedy Green]

I'm trying to measure the average cycle time for a loop in a thread
similar to this one:

You have two problems:
1. System.currentTimeMillis in only accurate to 50 ms on some systems.
See http://mindprod.com/jgloss/time.html

2. sleep(x) just means sleep AT LEAST x ms. There is no guarantee the
CPU will be free and the thread will start executing right away on
wakeup time. (There is a variant of sleep that takes a finer
resolution).

The best way to handle this sort of problem is to let a Ttimer do it.
There are two flavours. See http://mindprod.com/jgloss/timer.html
They will not be perfect, but that is the best you can do without a
RTOS.