Return-Path: X-Original-To: apmail-cloudstack-users-archive@www.apache.org Delivered-To: apmail-cloudstack-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6CA90105A5 for ; Thu, 15 Aug 2013 17:36:34 +0000 (UTC) Received: (qmail 39680 invoked by uid 500); 15 Aug 2013 17:36:02 -0000 Delivered-To: apmail-cloudstack-users-archive@cloudstack.apache.org Received: (qmail 39591 invoked by uid 500); 15 Aug 2013 17:35:55 -0000 Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cloudstack.apache.org Delivered-To: mailing list users@cloudstack.apache.org Received: (qmail 39552 invoked by uid 99); 15 Aug 2013 17:35:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 17:35:54 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rajujith@gmail.com designates 74.125.83.53 as permitted sender) Received: from [74.125.83.53] (HELO mail-ee0-f53.google.com) (74.125.83.53) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 17:35:48 +0000 Received: by mail-ee0-f53.google.com with SMTP id b15so512762eek.12 for ; Thu, 15 Aug 2013 10:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jr+/GijHZg1fNKDeRieMm+9TrjuwEhpZrDdoy43QUuE=; b=qJvHAmHcqY2g4divhV37bKGII1lVBXon8zrz2NuokP80FpyJkIilamq8bALfrQ4rrB Xnbg3AYH29AgKhCj79XQAYd2irb6ztEsCXRUhso254Nj8PuKnlfznuHckHH6+B4tlwgx aX3iXzx7potsFyIDjbeJhYpZ4qbcmwI6f37E9XwtFEEkpvHJE1Y5k7RB7JypcnxgXH/I aejJEyo1PapAknIYsQfC636dQX67mEAR+yOYWWSf9DI26weBYZJPxcARcTRyOT2RYqQs RT+5oPRB2+swHpuH4Tiiq6wug/1Pw0ccDVMArbTNZIcSQ0a9dOYpH++gdMWnVHzprRtw eoqA== MIME-Version: 1.0 X-Received: by 10.14.95.2 with SMTP id o2mr1113224eef.82.1376588127666; Thu, 15 Aug 2013 10:35:27 -0700 (PDT) Received: by 10.14.131.79 with HTTP; Thu, 15 Aug 2013 10:35:27 -0700 (PDT) In-Reply-To: References: <9680FA8C0C05444EB779EF386004349C@NexaB> Date: Thu, 15 Aug 2013 23:05:27 +0530 Message-ID: Subject: Re: Variable speed CPUs From: Jithin Raju To: users@cloudstack.apache.org Content-Type: multipart/alternative; boundary=001a1133d0ae5a269c04e3ffe6c0 X-Virus-Checked: Checked by ClamAV on apache.org --001a1133d0ae5a269c04e3ffe6c0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pete, Could you please compare your results with the output of dmidecode and 'cat /proc/cpuinfo' Thanks, Jithin On Thu, Aug 15, 2013 at 10:58 PM, Pete Johnson wrot= e: > I'm using AMD FX-8320 8-core 3.5 GHz processors with 16GB of unbuffered > ECC memory. (they're the best cost/performance processor available) > > - Pete > > -----Original Message----- From: Jithin Raju > Sent: Thursday, August 15, 2013 1:04 PM > > To: users@cloudstack.apache.org > Subject: Re: Variable speed CPUs > > Hi Marty, > > Not sure though, but I don't see the clock speed mentioned at the service > offering is set as a configuration parameter of the guest OS for kvm. > > Rather the clock speed set for the service offering is used as a referenc= e > of the resource utilization while allocating host for the instances > deployed using service offering. > > Pete: Which is the model number of the AMD processor you are using? > > From KVM perspective,We can specify the number of vCPUs to be allocated t= o > guests, also it supports which physical CPU to use: > "--cpuset=3DCPUSET > Set which physical cpus the guest can use. "CPUSET" is a comma > separated list of numbers, which can also be specified in ranges or cpus = to > exclude. Example: > > 0,2,3,5 : Use processors 0,2,3 and 5 > 1-5,^3,8 : Use processors 1,2,4,5 and 8" > > Thanks, > Jithin > > > On Thu, Aug 15, 2013 at 10:08 PM, Marty Sweet > wrote: > > In KVM and cloudstack 4.1.1 VM clock speed is enforced by the service >> offering set to the Guest VM. >> >> For example, if I were to make a service offering of 1vCPU running at 3G= hz >> and I only have a host running (at clock speed) of 2Ghz then cloudstack >> will refuse the start of the VM. >> >> You can see your processor statistics by running lshw -C CPU on the host= , >> the clock speed shown will be the actual host clock speed, regardless of >> BIOS technologies which may throttle or boost the frequency at anytime >> depending on load. >> >> Marty >> >> On Thursday, August 15, 2013, Pete Johnson wrote: >> >> > I am planning on running a mix of service offerings, mostly small but >> > their will be some pretty large database/processing servers using 2+ >> cores. >> > Won't know how large yet. >> > >> > - Pete >> > >> > -----Original Message----- From: Bradley Hieber >> > Sent: Thursday, August 15, 2013 12:07 PM >> > To: users@cloudstack.apache.org >> > Subject: Re: Variable speed CPUs >> > >> > What is the service offering for the guest machines? The service > >> offering >> > governs the type of virtual CPU presented to the guest. >> > >> > >> > On Thu, Aug 15, 2013 at 12:04 PM, Pete Johnson > > >wrote: >> > >> > Hi, >> >> I have build a small private cloud for an R&D project for one of my >> >> clients. I have 3 hosts each with 16gb memory and 8 cores (AMD) per >> host. >> >> I=92m using Cloudstack 4.1 and hosts are Ubuntu 12.04 w/KVM. The= se >> CPUs >> >> can vary clock speeds based on bios settings which is enabled. The >> >> Cloudstack dashboard correctly estimates the CPU clock speed at its M= AX >> of >> >> 3500 MHz. But, when I log onto the guests and run virt-top it says >> >> 1400MHz >> >> which I assume is its current throttled down clock speed. I am still >> >> setting things up and have not had the chance to put the hosts under >> >> enough >> >> load to see of it clocks up. My questions are: Does Cloudstack >> >> support >> >> viewable clocked CPUs in hosts? How does Cloudstack support variable >> >> clocked hosts from a real-time capacity load perspective and a usage >> >> perspective. >> >> Thanks >> >> Pete Johnson >> >> >> > >> > >> > >> > >> > -- >> > Brad >> > >> >> > --001a1133d0ae5a269c04e3ffe6c0--