From owner-freebsd-hackers@freebsd.org Sat Feb 25 20:02:44 2017 Return-Path: Delivered-To: freebsd-hackers@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 4A10ECED514 for ; Sat, 25 Feb 2017 20:02:44 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7EA1BD3 for ; Sat, 25 Feb 2017 20:02:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 57d932c1-fb95-11e6-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 57d932c1-fb95-11e6-95b5-6dfd7dbb0ee5; Sat, 25 Feb 2017 20:02:33 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1PK2Nmt001833; Sat, 25 Feb 2017 13:02:23 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488052943.25520.72.camel@freebsd.org> Subject: Re: Absolute timeouts and clock adjustments From: Ian Lepore To: Eric van Gyzen , Sebastian Huber , FreeBSD Date: Sat, 25 Feb 2017 13:02:23 -0700 In-Reply-To: References: <58AD5802.30908@embedded-brains.de> <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> <1487778365.73144.144.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 20:02:44 -0000 On Fri, 2017-02-24 at 15:26 -0600, Eric van Gyzen wrote: > > > > Using CLOCK_MONOTONIC doesn't avoid the issue, it just explicitly > > asks > > for the current behavior.  If the behavior you need is to wake up > > when > > CLOCK_REALTIME exceeds some value, you're still screwed. > > > > It would be easy enough to fix the current behavior by adding > > something > > like "if (timo > hz) timo = hz;" to the existing loop so that > > CLOCK_REALTIME gets re-checked once a second. > That would work, but I don't really like introducing spurious wakeups > just to  > handle a very rare event. > > How about this approach? > > https://reviews.freebsd.org/D9791 > > It's also not ideal, and it's obviously much larger than your > suggestion, but  > it's very cheap in the common paths. I would rather add low-frequency wakeups to handle a rare event than all that extra code complexity.  Anyone who requires real sleep accuracy won't be relying on a single call to nail the return time anyway.  The point of a 1hz wakeup is that it's cheap and easy to implement and good enough to keep code with casual timing requirements from locking up forever after a big clock step (which tends to happen on embedded systems without battery backed clocks). For code that really cares about accuracy (like basically everything we do at $work), the userland code will do its own looping, with a series of long sleeps (typically at 1hz) followed by a series of decreasing- length microsleeps to get the time right.  That's immune to ntpd/ptpd steering the clock hard, leap seconds, and other things that perturb accurate sleeps. But all in all, I don't have strong feelings about it either way. -- Ian