From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 25 09:17:47 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD08616A402 for ; Mon, 25 Feb 2008 09:17:47 +0000 (UTC) (envelope-from sharadc@in.niksun.com) Received: from in.niksun.com (210.18.76.166.sify.net [210.18.76.166]) by mx1.freebsd.org (Postfix) with ESMTP id 796E213C448 for ; Mon, 25 Feb 2008 09:17:47 +0000 (UTC) (envelope-from sharadc@in.niksun.com) Received: from sharadc.in.niksun.com (unknown [10.60.5.27]) by in.niksun.com (Postfix) with ESMTP id 0BD8B5D19; Mon, 25 Feb 2008 15:02:31 +0530 (IST) From: Sharad Chandra Organization: NIKSUN To: freebsd-hackers@freebsd.org Date: Mon, 25 Feb 2008 14:40:56 +0530 User-Agent: KMail/1.9.4 References: <200802221558.42443.sharadc@in.niksun.com> <200802221437.48293.wundram@beenic.net> In-Reply-To: <200802221437.48293.wundram@beenic.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802251440.56435.sharadc@in.niksun.com> Cc: "Heiko Wundram \(Beenic\)" Subject: Re: usleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 09:17:48 -0000 ,---- [Heiko Wundram (Beenic) wrote:] | Am Freitag, 22. Februar 2008 11:28:42 schrieb Sharad Chandra: | > Does usleep work for you? i just saw it is implemented over nanosleep | > which passes a struct timeval to "select". | | Quoting from POSIX: | | """ | The usleep() function will cause the calling thread to be suspended from | execution until either the number of real-time microseconds specified by | the argument useconds has elapsed or a signal is delivered to the calling | thread and its action is to invoke a signal-catching function or to | terminate the process. The suspension time may be longer than requested due | to the scheduling of other activity by the system. | """ Yes, exactly. "microseconds" is giving me image we can go up to 1 micro but not a single time it sleeps for that much, or +- 10-20 micro sec. does suspension time mean 1000 micro secs? | | See the last sentence, specifically. | | So, yes, the behaviour you're seeing is pretty much expected, simply | because _user_ processes are scheduled in timeslices, which depend on the | HZ setting of the kernel. I was looking some where and i found process switching time is around 10ms. That means time slice is 10ms. say some peace of code just called usleep or nanosleep and scheduling occurs so at least it will take 10 ms. I didn't find sleeping more than 10 ms if usec = 1 to few us. Similarly, For setitimer, it goes the same too. if my code is right value.it_interval.tv_sec = 0; /* Zero seconds */ value.it_interval.tv_usec = 000000; value.it_value.tv_sec = 0; /* Zero seconds */ value.it_value.tv_usec = 1; /* 1 us */ result = setitimer( which, &value, &ovalue ); gettimeofday (&t1, NULL); for( count=0; ((count