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

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to