From owner-freebsd-arch@FreeBSD.ORG Thu Mar 1 01:05:01 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ACD91065673 for ; Thu, 1 Mar 2012 01:05:01 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 066B38FC19 for ; Thu, 1 Mar 2012 01:05:00 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CC6957300A; Thu, 1 Mar 2012 02:23:15 +0100 (CET) Date: Thu, 1 Mar 2012 02:23:15 +0100 From: Luigi Rizzo To: Bruce Evans Message-ID: <20120301012315.GB14508@onelab2.iet.unipi.it> References: <20120229194042.GA10921@onelab2.iet.unipi.it> <20120301071145.O879@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120301071145.O879@besplex.bde.org> User-Agent: Mutt/1.4.2.3i Cc: arch@FreeBSD.org Subject: Re: select/poll/usleep precision on FreeBSD vs Linux vs OSX X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 01:05:01 -0000 On Thu, Mar 01, 2012 at 11:33:46AM +1100, Bruce Evans wrote: > On Wed, 29 Feb 2012, Luigi Rizzo wrote: > > >I have always been annoyed by the fact that FreeBSD rounds timeouts > >in select/usleep/poll in very conservative ways, so i decided to > >try how other systems behave in this respect. Attached is a simple > >program that you should be able to compile and run on various OS > >and see what happens. > > Many are broken, indeed. > > The simple program isn't attached. ... > > > > | Actual timeout > > | select | poll | usleep| > > timeout | FBSD | Linux | OSX | FBSD | FBSD | > > usec | 9.0 | Vbox | 10.6 | 9.0 | 9.0 | > > --------+-------+-------+--------+-------+-------+ > > 1 2000 99 6 0 2000 > > 10 2000 109 15 0 2000 > > 50 2000 149 66 0 2000 > > 100 2000 196 133 0 2000 > > 500 2000 597 617 0 2000 > > 1000 2000 1103 1136 2000 2000 > > 1001 3000 1103 1136 2000 3000 <--- > > 1500 3000 1608 1631 2000 3000 <--- > > 2000 3000 2096 2127 3000 3000 > > 2001 4000 3000 4000 <--- > > 3001 5000 4000 5000 <--- > > > >Note how the rounding (poll has the timeout in milliseconds) affects > > You must have synced with timer interrupts to get the above. Timeouts yes i have -- the test code does almost nothing after returning from a select, on a system that does some amount of work times could be up to 1000us shorter. Still a huge error on short timeouts. I should also comment that these are average values on an otherwise idle system -- i will try to post a histogram of the actual values, it might well be that osx and linux have quantized values very different from the average (though this would violate the specs, so i suspect instead that they have some cheap one-shot timers). For FreeBSD I have also rounded the bsd values (actual averages are -1/+3us over 1sec experiments). > timeouts at the cost of efficiency. But I don't like timeouts. When > they are used a lot, they are a form of busy waiting. This is only > acceptable if you have CPU to burn). sometimes you have no other way to get a notification. > It remains to explain why the above results show that poll() but not > select() is broken for small timeouts (they are turned into 0 us for no it is just that my application that does the rounding down as the API only accepts milliseconds. Thanks for the extensive comments. cheers luigi