From owner-freebsd-java@freebsd.org Thu Nov 12 17:19:34 2015 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F2F2A2C9C2 for ; Thu, 12 Nov 2015 17:19:34 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD1391CF3 for ; Thu, 12 Nov 2015 17:19:33 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id tACHBWjf010908; Thu, 12 Nov 2015 12:11:32 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Thu, 12 Nov 2015 12:11:32 -0500 (EST) Date: Thu, 12 Nov 2015 12:11:32 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Achilleas Mantzios cc: freebsd-java@freebsd.org Subject: Re: Thread.sleep is very incorrect on kern.hz FreeBSD-10 + openjdk8. In-Reply-To: <5644BD96.9000005@matrix.gatewaynet.com> Message-ID: References: <5644BB9A.4060807@smartspb.net> <5644BD96.9000005@matrix.gatewaynet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:19:34 -0000 On Thu, 12 Nov 2015, Achilleas Mantzios wrote: > On 12/11/2015 18:17, Sergey Potapov wrote: >> Hello! >> >> FreeBSD-10.1 without tunning. >> openjdk8 without tunning (pkg install). >> >> >> Thread.sleep depends on kern.hz sysctl variable. >> >> Simple program and more detailed version information attched. >> openjdk7 tested with kern.hz=2000 -- same results. >> >> kern.hz: 100 >> >> 1000 times Thread.sleep(1) 19994 milliseconds >> 1000 times Thread.sleep(2) 19997 milliseconds >> 1000 times TimeUnit.MICROSECONDS.sleep(100) 20000 milliseconds >> >> kern.hz: 1000 >> >> 1000 times Thread.sleep(1) 2002 milliseconds >> 1000 times Thread.sleep(2) 3000 milliseconds >> 1000 times TimeUnit.MICROSECONDS.sleep(100) 2001 milliseconds >> >> >> kern.hz: 2000 >> >> 1000 times Thread.sleep(1) 1500 milliseconds >> 1000 times Thread.sleep(2) 2500 milliseconds >> 1000 times TimeUnit.MICROSECONDS.sleep(100) 1500 milliseconds What timer are you using (kern.eventtimer.timer ?) and what scheduler (kern.sched.name)? Can you repeat the test by just using a C program and nanosleep()? Sleep is at the mercy of the granularity of HZ. If you ask to sleep for 1 millisecond at time T+.5msec, the kernel checks for wakeups at time T+1msec, but your thread isn't ready then - it has only slept for .5msec. So the next chance for a wakeup is at T+2msec. Hence, you effectively sleep for 1.5msec. When you are calling Thread.sleep(1) in a tight loop, most of the time you are probably going to be woken up just after a kernel timing tick. That means you will go to sleep just after the tick, e.g. T+.01msec, so the kernel can't wake you up at T+1msec because you haven't slept for the entire time. This is for HZ=100 example. It is similar for other HZ, and is probably why your sleep times all seem to have an extra kernel tick per sleep. You could also try Thread.sleep(0, 900000) which would be just under 1msec. If your program knows HZ, it could sleep for 1/2 of that relative tick, so on average it might sleep 1 tick. -- DE