Originally posted by: tech100

I get it so in both cases LPAR will have guaranteed 2 cores all the time?

what is the real difference between dedicated-donating and shared-uncapped of the same amount of desired processing units?

Originally posted by: CharlesLacour

This is an answer based on research, not experience, so take it with a grain of salt.

If the LPAR has dedicated cores, it can donate unused ones to the shared pool, but only as one entire core at a time. If it needs that core back for even the tiniest bit of processing, it takes the whole thing back, not just the little bit it needs.

A partition defined with shared-uncapped can borrow/lend processor time in smaller chunks (I couldn't find a clear statement whether it was .1 cpu or .01 cpu. What I read lead me to believe that you have to use 0.1 core chunks when defining things, but AIX and the Power Hypervisor can adjust it in 0.01 core chunks.

The number of virtual CPUs overrides a lot of things. If you only have 2 virtual CPUs defined, you're not going to get more than that, regardless of the maximum processing units being defined higher than two and the partition being uncapped. (In other words, it never maps more than one physical CPU to one virtual CPU.)

If you had two systems, one with 2 dedicated cores, the other with 2 shared cores (and 2 virtual CPUs defined), the dedicated system could donate 1 core if it wasn't using it. Otherwise it would have two.  The shared system could donate smaller fractions, down to 0.2 cores, or the minimum defined, if that's higher.  The maximum it could go would be 2 full cores.

If the shared system had 4 virtual processors defined, then it could go up as high as 4 cores (assuming that much spare capacity was available), and it's minimum would be 0.4 or higher.

Originally posted by: Wouter Liefting

There are three main reasons to use dedicated processors.

1. If your OS doesn't support shared processors, such as older AIX versions.

2. If you are doing real-time work (such as controlling robots) or work that requires really low latencies (VIO servers come to mind) and you cannot run the risk of not being active when an interrupt comes in.

3. If you are using licensed software that's tied to the CPU ID, so you need to make sure you get the same CPU every time, even after a cold restart of the managed system.

I don't know of any other reason to choose dedicated processors over shared processors.

If you have two dedicated processors you are obviously guaranteed to have these available. If you're in "dedicated-donating" mode, then their spare cycles will be donated to the shared pool if you're not using them. This is done on a per-timeslice basis (10 ms) and only if the actual usage is below 75% or so.

If you are using shared processors with an entitlement of 2.0, then you will be allocated the equivalent of two full CPUs per timeslice (10 ms). Depending on the number of virtual processors, this may be two CPUs for the full timeslice, or four 5 ms slices spread out across four CPUs, possibly all running in parallel. Or even twenty 1 ms slices spread across twenty CPUs, all running in parallel. The advantage of running "uncapped" is that if the other partitions are not busy, you can use the spare capacity in the shared pool. So if your LPAR needs it, it can theoretically use 200 ms worth of CPU time in each 10 ms time slice. But that requires that you have the number of virtual CPUs set to 20, and it requires that your OS and application are able to spread out the work across at least 20 threads.

Dedicated-donating will behave very much like shared-capped. You are guaranteed two CPUs (or, at least, the equivalent processing power of two CPUs), any unused cycles will be fed back to the shared pool, but you cannot exceed two CPUs (or equivalent). Once you go from shared-capped to shared-uncapped, you can use the excess cycles in the shared pool if they're available, but only if you have defined sufficient virtual processors, and if your OS and application have enough threads to do so.

Tuning CPU performance, especially when using shared-uncapped is a pretty complicated affair with lots of variables and issues to consider. There are some rules of thumb, but to do things properly you first need to understand the application(s) that are running, and what you're trying to achieve.

Originally posted by: tech100

software testers needed it to have "valuable test results every new software release"

Originally posted by: Wouter Liefting

In that case I agree. If you want to benchmark your software, you will want to have as little outside variables as possible. Use dedicated, non-donating mode processors in that case. Also do not use AME and AMS, and try to avoid the use of a VIO server if at all possible.