Timing

[swpalmer]

[quote]The timers in windows based systems are not accurate and other background processes will cause inaccuracies.
…
The docs say that you will never get super accurate results because windows does NOT count actual CPU cycles devoted to a process. So the timings a estimates at best. (Making sure all your background processes are switched off will help)
[/quote]
Background processes have no effect on hardware timers, I think you are confused. At worst the timer would lag if hardware interrupts were missed because of some other high priority code locking out the ISR for too long.

Remember we are measuring REAL time, not the amount of time that our process gets the CPU.

[mthornton]

[quote]My experience of this is in profiling my Prolog program. (using SCI Prolog FYI)The docs say that you will never get super accurate results because windows does NOT count actual CPU cycles devoted to a process.
[/quote]
Windows NT, 2000, XP do count CPU time for each thread and process. Windows 9X and ME do not. The resolution is limited to that of the system clock (usually 10ms on single processor machines and 15.625ms on multiprocessors).

However as someone else has pointed out real time rather than CPU time is the subject of this thread.

[mthornton]

Background processes have no effect on hardware timers, I think you are confused. At worst the timer would lag if hardware interrupts were missed because of some other high priority code locking out the ISR for too long.

Windows system time is initialised from the hardware clock at boot but subsequently runs independently. It can and does drift if interrupts are missed (these days rather rare). It has also been found to drift if the clock period is changed too often (a side effect of using Thread.sleep(1) — there is a bug in the bug parade relating to this. http://developer.java.sun.com/developer/bugParade/bugs/4500388.html

This drift may be corrected if an NTP client is in use.