Re: [KVM-AUTOTEST][PATCH] timedrift support

[Yaniv Kaul <ykaul@redhat.com>]

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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>