From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bear Yang Subject: Re: [KVM-AUTOTEST][PATCH] timedrift support Date: Mon, 18 May 2009 09:54:39 +0800 Message-ID: <4A10BFDF.6040405@redhat.com> References: <4A010BCD.8060307@redhat.com> <20090506130247.GA5048@amt.cnet> <4A08008E.8060105@redhat.com> <1242046789.2930.8.camel@localhost.localdomain> <4A096C28.1060900@redhat.com> <4A09748C.6040909@redhat.com> <1242239695.2620.18.camel@localhost.localdomain> <4A0D98B8.2070705@redhat.com> <4A0F23E7.9030402@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Lucas Meneghel Rodrigues , Marcelo Tosatti , uril@redhat.com, kvm@vger.kernel.org, Lawrence Lim To: Yaniv Kaul Return-path: Received: from mx2.redhat.com ([66.187.237.31]:40489 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751802AbZERBxd (ORCPT ); Sun, 17 May 2009 21:53:33 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n4I1rYe2017168 for ; Sun, 17 May 2009 21:53:34 -0400 In-Reply-To: <4A0F23E7.9030402@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? 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? 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. 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. 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