[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] HVM clock running at lightspeed?
On Feb 8, 2008 3:46 PM, Tom Horsley <tom.horsley@xxxxxxx> wrote: > On Fri, 8 Feb 2008 15:34:29 -0800 > [...] > I'm not sure what fixed it, but I noticed that the failsafe boot didn't > have the problem, and when I copied "apm=off acpi=off noapic" that the > failsafe boot had to the primary kernel boot parameters, the problem > disappeared (I have no idea why that made it disappear, or which > one was important :-). Outstanding! However...my guess is that nothing actually "fixed" the problem, and that if you went back to the same conditions as when it happened last time - _really_ went back... which is sometimes downright impossible... that you'd find that particular HVM time-skew problem to still be right where it's always been. I hope. I'll explain that better below, (again) I hope. It's awesome that you've got HVM virt working much better with the triad of kernel params you've mentioned above - that qualifies as a "major clue" (read: it should be in a FAQ somewhere if it isn't yet) both (1) for others who want to get HVM virt working well, and (2) for me in particular, since _omitting_ those options as part of my testbed scenarios never even entered my mind until I found out you'd experienced problems when (accidentally) omitting them. So... Thank you - big time! (getting tired of the time-related puns yet? are they... untimely?) The wallclock on your HVM may or may not be "right" now, though. From what you've said, things appear _much better_ and the wallclock is not wildly out of kilter as it was before. You'll still want to keep a close eye on it, test it slowly - not quickly - for example, ask it what time it is every hour, and see if it stays relatively accurate or if there's a tendency for the answer to get, pardon my non-english, wronger-and-wronger over time. That test is much more telling than say, a forever loop that prints a timestamp then sleeps for one second. In the second case, the observer's become way too much a part of the equation to be providing really useful and/or (time-)telling information; its results are in fact often totally misleading as compared to the results of a more subtle wallclock-sampling approach. My recent development effort (the ruby-based time monitor and skew-correcting feedback-loop) is being influenced by a lot of fun design criteria - including subtlety, a careful attention to the fact that observers really _are_ part of whatever equations they're in... but mostly it's been fueled by a driving need for something solid to help with the particularly thorny issue of wallclock skew in virtual environments. ...I seem to be putting this thing more and more on my own "front burner" now, aren't I? ...that's a sign maybe I'll finish it up and release it sometime soon. :-) -pbr _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |