From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 18:21:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE3A11065670 for ; Mon, 21 Feb 2011 18:21:08 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id C548F8FC08 for ; Mon, 21 Feb 2011 18:21:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp027.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LGZ00AESCAUFQ00@asmtp027.mac.com> for freebsd-current@freebsd.org; Mon, 21 Feb 2011 10:20:56 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-21_05:2011-02-21, 2011-02-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102210083 From: Chuck Swiger In-reply-to: <4D6291A5.4050206@netasq.com> Date: Mon, 21 Feb 2011 10:20:54 -0800 Message-id: <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> References: <4D6291A5.4050206@netasq.com> To: Jerome Flesch X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org Subject: Re: Process timing issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 18:21:08 -0000 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