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
|
