The smallest time element is a tick. A tick is not always a second multiple. Internally WaitOne convert the timeout in tick and round it under.

On very fast machine you can exit before expected time (some micro second before + very fast machine = expected time is not correct).

Remi Thomas has not indicated that the parameter to WaitOne() is a tick count. He/she has indicated that the time parameter (in milliseconds) is converted to ticks, which is correct. Even if this conversion is exact, the real elapsed time is not exact (for several reasons). In the case addressed here, the suggested inaccuracy arises from rounding the tick count to an integer (and it is suggested that this rounding may be downward).

It is not clear from what is presented that this is a greater problem on a "fast" machine. Such machines are likely to have faster "ticks" and so timing is likely to be more accurate. Generally, it is advisable to round up a "tick" count to avoid a delay less than required (because of rounding down in conversion from milliseconds and because a wait for N ticks may always give a delay less than N tick times, because the first 'tick' always occurs less than one tick period after the call.

So, the "milliseconds" parameter should be increased at least one tick beyond the minimum tolerable delay. Since the tick time may vary from one machine to another, the simplest solution is usually to increase the parameter by some time which exceeds the tick time on all likely machines. Usually, it is possible to choose such a time increase which does not spoil the application.

Remember also that WaitOne() is not intended to provide accurate timing. The actual delay achieved will often be much greater, due to other activity in the machine.