Re: Process timing issue

On Feb 21, 2011, at 8:24 AM, Jerome Flesch wrote:
> While investigating a timing issue with one of our program, we found out something weird: We've written a small test program that just calls clock_gettime() a lot of times and checks that the time difference between calls makes sense. In the end, it seems it doesn't always do.
> 
> Calling twice in a row clock_gettime() takes usually less than 1ms. But with an average load, about 1 time in 200000, more than 10ms are spent between both calls for no apparent reason. According to our tests, when it happens, the time between both calls can go from few milliseconds to many seconds (our best score so far is 10 seconds :). Same goes for gettimeofday().

A scheduler quantum of 10ms (or HZ=100) is a common granularity; probably some other process got the CPU and your timer process didn't run until the next or some later scheduler tick.  If you are maxing out the available CPU by running many "openssl speed" tasks, then this behavior is more-or-less expected.

> We tried setting the test program to the highest priority possible (rtprio(REALTIME, RTP_PRIO_MAX)) and it doesn't seem to change a thing.
> 

> Does anyone know if there is a reason for this behavior ? Is there something that can be done to improve things ?

FreeBSD doesn't offer hard realtime guarantees, and it values maximizing throughput for all tasks more than it does providing absolute minimum latency even for something wanting RT.  There has been some discussion in the past about making RT tasks with very high priority less pre-emptible by lower priority tasks by removing or reducing the priority lowering that occurs when a task gets allocated CPU time.

What problem are you trying to solve where continuous CPU load and minimum latency realtime are both required?

Regards,
-- 
-Chuck