Re: Process timing issue

On Feb 22, 2011, at 1:22 AM, Jerome Flesch wrote:
>> 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 did most of our tests with kern.hz=1000 (the default FreeBSD value as far as I know) and we also tried with kern.hz=2000 and kern.hz=10000. It didn't change a thing.

For a long time kern.hz=100 was the default; more recent versions have switched to kern.hz=1000, which is beneficial for minimizing latency for things like ipfw/dummynet processing, but also involve greater scheduler overhead.  kern.hz=10000 is likely to reduce performance and may have odd effects upon certain kernel timers.

> Also, we are talking about a process not being scheduled for more than 100ms with only 1 instance of openssl on the same CPU core. Even with a scheduler quantum of 10ms, I find that worrying :/

It depends on what else the machine is doing.  Gathering some data via acct/sa might be informative, as you might be running some other tasks via cron or whatever which your testing isn't expecting.

> We expected both processes (the test program and openssl) to have each half the CPU time and being scheduled quite often (at least once each 10ms). According to the output of our test program, it works fine for most of the calls to clock_gettime(), but from time to time (about 1 loop in 200000 on my computer), we have a latency pike (>= 100ms).
> 
> Thing is, these pikes wouldn't worry us much if they wouldn't last longer than 1s, but they do on some occasions.

Also, are you sure that you don't have ntpdate or ntpd or something else adjusting your system clock underneath you...?

Regards,
-- 
-Chuck