On 5/18/2009 4:54 AM, Bear Yang wrote:
Hello Yaniv Kaul:
I am understand your means for timedrift testcase.
* give up using ntp to query and sync the clock from guest to host. my
question is below:
1. why we can not using the NTP staff in timedrift test case? Is there
some positive bugs were point on NTP or we found that something of NTP
definite blocked us to using it? Or could you give me what exact we
need give up NTP in timedrift test case?
Just another requirement from the host we do not really need. And a bit
more hassle to configure on Windows. And who knows how to configure on
operating system this-or-that.
2. for your algorithm:
MeasureHostParams() // don't forget to measure the host's CPU, memory,
I/O and network data - always useful.
while (!enough)
{
RunAnotherVM() // don't forget to call SleepTillVmIsFullyRunning()
ForEachVM // this runs in parallel on the VMs
{
before = TimeOnHost()
RunXMinutesLoadOnGuest(load, minutes) // load can vary -
synthetic CPU, I/O or 'real life' load. Can also vary from VM to VM.
after = TimeOnHost()
drift = after - before
If(drift >= TooMuch) // How much is too much? Could be in
percentage or absolute values.
enough = true
}
}
Why get time from host(TimeOnHost()), why?I think it should be
TimeOnGuest(). Could you kindly tell me the details about how to get
the value of before/after and drift?
I don't need to get the time on the guest. I know I've asked it to run a
load for X minutes. The guest has run that for what it think is X
minutes - but may be X+drift minutes - because its clock drifted. If I
want to know by how much, I need to compare to a reliable source - the
host (or in our case, the test server actually).
3. you suggest that the loaded is runing on host is prefer than
running on guest and running several guest on host to make load on
host. right? why? nowadays, I using the stress program which provided
by Lucas just running in guest.
Good, load the guest. But if the host can satisfy the guest's
requirements, it won't be drifting (I hope!). We need to overload a bit
here. The most natural way is with more VMs.
4. I also want to know the result that the script works on your
side.Maybe it is more easy to help me understand your algorithm than
read the script.
We'll need to run it. Haven't run it for a while actually.
Y.
thanks for your explanation
Yaniv Kaul wrote:
On 5/15/2009 7:30 PM, bear wrote:
Good morning you all. :)
Lucas:
Very appreciated your help on try...except block implementation. I
am finally understand your means when I read the mail. :(
I modified the timedrift case in several place again.
1. add more comments in script.
2. functional the snippnet of script which get clock resource from
guest and host.
3. using vm.get_command_status replace the sendline API when complie
the stress program in guest area.
If there is something need to be done by me for the script. feel
free just kick me.
Happy weekend.
Hi Bear,
Please drop the NTP stuff. There's no need for it.
Llet me again suggest my algorithm (pseudo-code, of course):
MeasureHostParams() // don't forget to measure the host's CPU,
memory, I/O and network data - always useful.
while (!enough)
{
RunAnotherVM() // don't forget to call SleepTillVmIsFullyRunning()
ForEachVM // this runs in parallel on the VMs
{
before = TimeOnHost()
RunXMinutesLoadOnGuest(load, minutes) // load can vary -
synthetic CPU, I/O or 'real life' load. Can also vary from VM to VM.
after = TimeOnHost()
drift = after - before
If(drift >= TooMuch) // How much is too much? Could be in
percentage or absolute values.
enough = true
}
}
Simple algorithm, works for us, does not require NTP, and loads the
host in the most natural way it will be loaded in real life - by more
VMs.
Slight variations are possible. For example, use the first VM as a
'canary' VM - and measure only on it - the others can do random load;
pin down VM to CPUs; vary the load, the VMs used, and the time, etc.
HTH,
Y.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
