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 13:18:48 +0800 Message-ID: <4A10EFB8.4040404@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> <4A10BFDF.6040405@redhat.com> <4A10E1F4.7090902@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]:38186 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbZERFRk (ORCPT ); Mon, 18 May 2009 01:17:40 -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 n4I5HgI2024892 for ; Mon, 18 May 2009 01:17:42 -0400 In-Reply-To: <4A10E1F4.7090902@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Hello Yaniv Kaul: my comments is below. Yaniv Kaul wrote: > 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. Actually, I still have not a clear realize about why not give up NTP in timedrift test case. just for could not run this mode on windows guest? Except this NTP have not problem internally to block us to use it? right? I have working on TimeDrift problem base on KVM for several months, now you pointed out that we do not need NTP. you really need give me a reasonable reason or explanation for this at first. because If I give up NTP, that mean I need rewrite the TimeDrift case. the bug related my case will be abolished and my work on this will be abolished. >> >> 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). Yes, we need get the compare between host clock and guest clock whatever we useing NTP or not, please tell me how to get this comparison in your algorithm clearly. and show me how exactly you implement it for the value(before/after and drift) We purpose is found out if *Guest* has time drift problem. KVM is full virtualizaiton technology, guest does not know it running as a guest. so Why we need add the loaded to Host? BTW, my script now have the ability to configre option from control file to running stress testing just for X minutes or X hours? >> >> 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. I don't catch your means for your sentence "load the guest. But if the host can satisfy the guest's requirements, it won't be drifting (I hope!)." Could you please explain it for me? > >> >> 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 >> >