Date: Tue, 16 Oct 2012 14:01:31 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: Maxim Sobolev <sobomax@freebsd.org>, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Garrett Cooper <yanegomi@gmail.com>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r241576 - in head/usr.sbin/cron: cron crontab lib Message-ID: <20121016133233.I1358@besplex.bde.org> In-Reply-To: <1350335891.1123.160.camel@revolution.hippie.lan> References: <201210150821.q9F8Lobc047576@svn.freebsd.org> <20121015202615.GJ1383@garage.freebsd.pl> <1350333885.1123.153.camel@revolution.hippie.lan> <CAGH67wSATkcsMMFcd3=rkM%2BDZ=g-ke67zeuXd9RZ-=UY_9sdLg@mail.gmail.com> <1350335891.1123.160.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Oct 2012, Ian Lepore wrote: > On Mon, 2012-10-15 at 13:52 -0700, Garrett Cooper wrote: >> On Mon, Oct 15, 2012 at 1:44 PM, Ian Lepore >> <freebsd@damnhippie.dyndns.org> wrote: >>> On Mon, 2012-10-15 at 22:26 +0200, Pawel Jakub Dawidek wrote: >>>> On Mon, Oct 15, 2012 at 08:21:50AM +0000, Maxim Sobolev wrote: >>>>> ... >>>>> >>>>> Log: >>>>> Add per-second scheduling into the cron(8). Right now it's >>>>> only available via the new @every_second shortcut. ENOTIME to >>>>> implement crontab(5) format extensions to allow more flexible >>>>> scheduling. >>>>> ... >>>> >>>> Do I read the code correctly and the cron deamon will wake up every >>>> second now even if @every_second is not used at all? >>> >>> It appears to, which I don't think is a bad thing at all. But the way >>> it waits is to wake up, do some work, and go back to sleep for an >>> integer 1 second. That will occasionally lead to a second in which no >>> wakeup happens, as the "do some work" part always takes some fraction of >>> a second. >> >> This is silly. It should be waking up at the lowest common >> denominator of time quanta, not every second; this could be determined >> via the crontab its managing. > > In 1987 I would have been outraged at waking up at 1hz needlessly. > Sitting here typing on a machine that's doing 12,000 interrupts/sec just > to maintain clocks, and top shows interrupts using 0.0% cpu, it's hard > to get too upset about a 1hz loop anymore. It's more outrageous now, since there are more battery-powered systems and even mains power is much more expensive. In 1987 I didn't worry about kernel clock interrupts at 60 Hz, but they are outrageous now too :-). Clock interrupts normally aren't accounted for properly. With proper accounting, I've seen them taking 1-10% on bad systems in 1987 and 2007, but 0.1% is more normal. Even a fast x86 probably takes 1 microsecond per clock interrupt to do almost nothing, so the bad default of HZ = 1000 costs 0.1%, and HZ = 10000 costs 1%. > On the other hand, if people are going to rely on this new feature of > being able to execute something every second, then the integer sleep > needs to be changed to a nanosleep() calculated to truly wake up at a > 1hz rate without eliding seconds now and then. My version of ping does this so as to send out packets every second instead of drifting at a rate of approximately 2/HZ per second (normal ping sends a packet and then tries to wait for 1 second but actually waits for 1 second plus the scheduling granularity (rounded up) plus any scheduling delay. Then it has a minor delay sending the next packet before trying to wait for 1 second again). The drift is very noticable if the scheduling granularity is large. I use select timeouts for this (ping already uses select timeouts and I just calculate the time to the next second instead of always using 1), but I now think this would be better implemented as a periodic itimer. Old versions of ping used non-periodic alarms and had significant (at least in 1987-1997) system overheads from this (for restarting the alarms), so ping was changed to use select timeouts. It still has to restart the timeouts but this now happens in the same syscall that waits for a packet to come back. cron should care more about waking up at exact seconds boundaries. Periodic itimers aren't accurate enough for this (they drift, but at a constant rate). Except high resolution timers might "fix" this using lots more clock interrupts and outrageous slowness to get precise timing. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121016133233.I1358>