X-Spam-Check-By: sourceware.org Date: Mon, 26 Feb 2007 09:37:14 -0800 From: Christopher Layne To: cygwin AT cygwin DOT com Subject: Re: does usleep() sleep more than it's supposed to? Message-ID: <20070226173714.GB22638@ns1.anodized.com> References: <45E292D6 DOT 30906 AT gmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E292D6.30906@gmail.com> User-Agent: Mutt/1.5.11 X-Assp-Spam-Prob: 0.00000 X-Assp-Whitelisted: Yes X-Assp-Envelope-From: clayne AT ns1 DOT anodized DOT com X-Assp-Intended-For: cygwin AT cygwin DOT com X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Mon, Feb 26, 2007 at 03:57:10PM +0800, Carlo Florendo wrote: > Good Day, > > I'm writing an application that requires time precisions up to the > microsecond level. However, I put a hard-coded adjustment of > 9000 microseconds since usleep() seems to sleep on the average of > 9000 microseconds more than it's supposed to, at least on my > system. I could work with up to 2000 microseconds for > function overhead but 9000 microseconds seems to be too long. Without using POSIX Realtime extensions, you will *never* attain consistent granularity at the microsecond level with any sleep() function. Think about it - on a preemptive multiprocess OS - the minimum intervals the OS uses for handing out timeslices to all processes contained within the current environment (and also the associated forced sleeping of processes who have used too many of their timeslices within a given interval) will always limit your granularity. -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/