Re: sampling rate problem
On Fri, 10 Nov 2006, wanwan wrote:
I have a thread that records mouse positions at 100Hz, but I can't get
the desired sampling rate. The simplified code is:
static int mousepos_x, mousepos_y; // updated by another class
int[][] samples = new int [15000][2];
int count = 0;
....
public class SampleMouse implements Runnable {
....
public void run () {
while (running) {
samples[count][0] = mousepos_x;
samples[count++][1] = mousepos_y;
Thread.sleep(10);
}
}
}
I also tried in the run method with another algorithm:
long starttime; // (class scope variable) in ns
while (running) {
if (System.nanoTime() > starttime + count*10*1000000) {
samples[count][0] = mousepos_x;
samples[count++][1] = mousepos_y;
}
}
I also tried setting the thread priority to max.
With any of the approaches, I get a discrepancy of over 20%
Does anyone have a good way to get the desired sampling rate?
You have a tough problem on you hands.
Short of using the java realtime spec and a realtime OS this is not
something you can do reliably in java. It is also going to be OS and
harware dependent due to various thread scheduling policies.
I have had some success (~60Hz) on non-realtime OS by interfacing with
native timers via JNI. On windows look at the multimedia timer, on linux
you might try the rtc timer. You are still going to have to contend with
scheduling jitter and GC whenever you cross the jni boundry.
If you are not concerned about jitter and want a high sampling rate
consider using a native solution (multimedia timer, rtc, hpet) to collect
the data at (near) the desired rate. Deliver this data to the java
side of the application (via jni or some IPC like a socket) at a lower
frequency. If ever your sampling thread crosses jni into the java side of
things you can kiss 100HZ behind.
If you are using linux and your sampling code is *very* tight you can get
decent scheduling stability with the SCHED_FIFO policy and the rtc timer.