On 2011/06/03 19:52, Sam Trenholme wrote:
I have seen a recent thread about the clock drift issue in Scientific
Linux 5 (SL5) and would like to share my thoughts.
I have had issues with clock drift running SL5 in a Virtualbox
environment (Windows host, SL5 guest) ever since I installed SL5. I
would madly reinstall the guest tools, change the kernel boot
parameters, and the issue would go away. For a while.
But, inevitably, the time drift problem came back. I did some more
research and saw this bug report:
http://www.virtualbox.org/ticket/3135
After trying all of the possible kernel boot parameters, with no luck
improving things, I finally thre in the towel and set up a crontab to
update the clock via NTP once a minute (which would be about two
minutes of real time in the guest).
This was not a real solution, so I ended up spending over eight hours
upgrading my system to SL6 (I tried and failed to "upgrade", and had
to do a fresh install of SL6 then transfer files over form the SL5
system; I also discovered the hard way one needs to give a SL6 VM
guest 512 megs of memory to do a graphical install, which I needed to
install a working system).
One Linux user has told me that the SL5 clock slew problem only
happens when the host is a Windows host.
Another thing: Yes, upstream is deprecating aspell, but if SL6 is
going to have an aspell package, it makes sense to also give it
packages for all of the dictionaries, even if they are unofficial
add-ons. If the intention is to upgrade to hunspell, "aspell" should
be a symlink to hunspell (just as "ispell" is a symlink to aspell), so
that "aspell -c" and "aspell -a" do the right thing.
- Sam
Sam, I have an out of the box "Desktop" install for SL6 64 bit on a
Windows 7 64 bit VirtualBox. I decided to check this situation out.
I found that simply booting the "machine" was enough to get the timing
well off what it should be, moving off at a rapid rate. However, after
stopping ntpd, setting time with ntpdate, and restarting ntpd let it
settle down. I can see there is an apparent clock bias. The ntpd
feedback loop is stuck offset from ideal time by about 60 ms to 90ms.
I also note that is what the old Fedora 4 machine it connects to says
for itself, too. But that does not show up in as a time difference in
the SL machine when I check with ntpq.
This is the current "peers" report
remote refid st t when poll reach delay offset jitter
==============================================================================
+name1.glorb.com 128.174.38.133 2 u 26 64 377 91.031 73.142 12.195
+208.52.173.46 130.207.244.240 2 u 12 64 377 77.893 69.564 16.652
-atlas.pagethrow 64.147.116.229 2 u 6 64 377 35.290 98.202 20.265
*192.168.37.10 132.239.1.6 2 u 13 64 377 0.351 59.526 11.604
The SL6 machine has been mostly idle during the test over the last
two days. But I've been using the Win 7 machine in a normal fashion
browsing, compiling, and watching YouTube videos. Note that I have
not paused the SL6 at any time. I suspect that would be "deadly". (I
figure a little script to perform the dance above would be sufficient
to get it back on track, though.)
I just reran the Win 7 machine's SNTP "once a day" check and it
jumped forwards 15 seconds. SL6, if anything, developed less spread
in the delays. They're all 60-67 ms now.
I'm going to keep experimenting with this to see if the "restart ntp"
trick is a viable work around.
{^_^} Joanne
