[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] HVM clock running at lightspeed?
Greetings, Tom! I smiled as I read your note; you've given me a great starting point for this email. I've not only seen similar oddities as you've described, myself, in the past, but I also I believe you're spot-on in your analysis of what's going on; "wall time" is passing too quickly on your HVM. Here's a 50-000-foot-level-overview of the issues of time in context of virtualization: - some HVMs run slower than reality, some faster - some Paravirts run slower than reality, some faster - sometimes they run great for a while THEN go whacky - sometimes they run wacky for a while then get more stable - time issues/constraints/ during virtual host boot are very much different from running stable-state - time skew (more accurately, VH wall-clock vs. Dom0 wall-clock skew) isn't consistent, predictable, or even predictably skewed in the same direction I've had the recent pleasure of working on 'the time problem' with a client, and they've agreed verbally that I can release the time monitoring stuff I've designed and partially built for them; I'm in the process of cleaning it up and 'completing' it on my own dime. There may or may not be better or more expedient routes for you to take to get to the bottom of your problem... but, as a bit of potential "light at the end of that tunnel", I'll share what I'm personally doing to help along these lines. A pretty simple (but very longly named) Proportional-Integral-Derivative control loop should be able to be put in place to quite effectively dampen and correct for the time skews as and when they occur in VMs. An ongoing and dynamic corrective measure for time on VMs is preferable to a brute-force "trying to tell the OS on the VM what time it is" approach. What I've built so far is Ruby-based, lightweight (so as to keep the "observer" as minimal a part of the equation as possible), thread-safe (pretty much), and only half of a real solution. The first step is collecting the data right... then once we have a reliable means of assessing the (current) skews of a set of VMs, we can instrument a PID control for each of them to dynamically correct them whenever they start to get their wallclocks skewed. Tom, if you (or anyone else reading this) would like to be part of this effort, I welcome your input and your energy. I can't say when it'll emerge, since it's not a "front burner" project for me right now (though it is mighty compelling) - thus any and all help from others to get a framework such as the above in place would be quite appreciated. Best regards, -Paul Reiber http://Reiber.org _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |