[arch-dev-public] [PATCH 1/3] rc.sysinit: background hwclock calls
hwclock calls appear to block somewhere between 1 and 2 seconds when we have
back-to-back calls. My theory (without looking at the code) is that hwclock
has to synchronize to the 1 second intervals of the hardware clock, so it
can sometimes take up to a second to complete.
To get around this unpleasant behavior, we can background the calls at point
X in the boot sequence, and then later at point Y in the script (when we
absolutely need the clock actions to be complete), we wait on the
subprocess. This allows the rest of the boot sequence, after the hwclock
code block, to continue until the point where we wait on the subprocess.
Signed-off-by: Dan McGee
Signed-off-by: Dan McGee
This is an Arch initscripts original (commit 98c76a4), but is not actually
necessary for hwclock to operate correctly, so kill it. The file is created
automatically when `hwclock --systohc` is invoked.
Signed-off-by: Dan McGee
On Sun, Dec 13, 2009 at 9:26 PM, Dan McGee
hwclock calls appear to block somewhere between 1 and 2 seconds when we have back-to-back calls. My theory (without looking at the code) is that hwclock has to synchronize to the 1 second intervals of the hardware clock, so it can sometimes take up to a second to complete.
To get around this unpleasant behavior, we can background the calls at point X in the boot sequence, and then later at point Y in the script (when we absolutely need the clock actions to be complete), we wait on the subprocess. This allows the rest of the boot sequence, after the hwclock code block, to continue until the point where we wait on the subprocess.
Signed-off-by: Dan McGee
---
I discussed this patch series with Thomas a while back; I'd be happy to answer questions on it. They have worked great on my Eee over the last month. -Dan
On Sun, Dec 13, 2009 at 9:28 PM, Dan McGee
On Sun, Dec 13, 2009 at 9:26 PM, Dan McGee
wrote: hwclock calls appear to block somewhere between 1 and 2 seconds when we have back-to-back calls. My theory (without looking at the code) is that hwclock has to synchronize to the 1 second intervals of the hardware clock, so it can sometimes take up to a second to complete.
To get around this unpleasant behavior, we can background the calls at point X in the boot sequence, and then later at point Y in the script (when we absolutely need the clock actions to be complete), we wait on the subprocess. This allows the rest of the boot sequence, after the hwclock code block, to continue until the point where we wait on the subprocess.
Signed-off-by: Dan McGee
--- I discussed this patch series with Thomas a while back; I'd be happy to answer questions on it. They have worked great on my Eee over the last month.
These look good to me. Feel free to push them if no one else takes issue with it
On Sun, 13 Dec 2009 21:26:46 -0600
Dan McGee
This is an Arch initscripts original (commit 98c76a4), but is not actually necessary for hwclock to operate correctly, so kill it. The file is created automatically when `hwclock --systohc` is invoked.
hmm can't find any mention of 'systohc' in the current rc.init, nor in your other patches? Dieter
On Thu, Dec 17, 2009 at 5:54 AM, Dieter Plaetinck
On Sun, 13 Dec 2009 21:26:46 -0600 Dan McGee
wrote: This is an Arch initscripts original (commit 98c76a4), but is not actually necessary for hwclock to operate correctly, so kill it. The file is created automatically when `hwclock --systohc` is invoked.
hmm can't find any mention of 'systohc' in the current rc.init, nor in your other patches?
rc.shutdown is where that is, but I may have mean hctosys. I don't know because these patches are a month or so old and I can't look into it at the moment. -Dan
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Dan McGee
-
Dieter Plaetinck