Date: Sat, 25 Feb 2017 13:02:23 -0700 From: Ian Lepore <ian@freebsd.org> To: Eric van Gyzen <vangyzen@FreeBSD.org>, Sebastian Huber <sebastian.huber@embedded-brains.de>, FreeBSD <freebsd-hackers@freebsd.org> Subject: Re: Absolute timeouts and clock adjustments Message-ID: <1488052943.25520.72.camel@freebsd.org> In-Reply-To: <bb91620e-8fbf-db73-82ca-704ea01a182d@FreeBSD.org> References: <58AD5802.30908@embedded-brains.de> <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> <1487778365.73144.144.camel@freebsd.org> <bb91620e-8fbf-db73-82ca-704ea01a182d@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1488052943.25520.72.camel>