I agree Wido, it's just that it's wrong - there should be no implicit CPU over-provisioning by default - and yes, later you can do over-provision by 2-3 as most of us do... just something that hurts my eyes :)
On Fri, 28 Dec 2018 at 11:39, Wido den Hollander <w...@widodh.nl> wrote: > > > On 12/28/18 9:23 AM, Andrija Panic wrote: > > Hi guys, > > > > > https://github.com/apache/cloudstack/commit/29e389eb872ffa816be99aa66ff20bdec56d3187 > > > > this one gets above gets CPU frequency with "effectively > > "cat sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq" which gives > the > > TurboBoost CPU frequency (in case of Intel CPU) and similar for AMD. > > > > Problem is that TurboBoost can only boost frequency of a very small > number > > of CPU cores for a period of time - not by any means all cores. > > > > CPU frequency is wrongly reported here as i.e. 3.4 GHz instead of 2.6 GHZ > > (example of Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz) > > > > We here thus have effective over-provisioning of 30% by default. > > > > Can we fix this somehow to actually read the base CPU frequency ? > > i.e. Xen reports correct CPU frequency (base/nominal one) > > > > Probably fixable by reading a different file on the KVM hypervisor. But > I always have the feeling that Ghz are a soft factor. Memory and Storage > are hard limits, but CPUs are different. > > We have a over provision of 2x of 3x on many systems as the CPUs are > pretty much idle and the defaults of CS are very conservative. > > What does a Ghz really tell us? A Ghz from 5 years ago isn't the same as > one from today. > > Wido > > > Best, > > > -- Andrija Panić
