Power

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

Explaining part 1.

You have to look up the server rPerf value - this covers the whole server with certain set numbers of cores.

Note if your old Power AIX sever is not using a virtual machine but is using the entire servers then you don't need to do this first scale down.

Scale 1:

For example, there may be rPerf numbers for a particular server for 8, 16, 24 and 32 CPU cores.

If you logical partition (virtual machine) does not have one of these four CPUs count then you need to calculate the rPerf.

If your virtual machine has 10 CPU cores then scale by taking the rPerf for 16 CPU cores the divide by 16 and multiply by 10.

Scale 2:

Then, if your virtual machine only ever gets to say 25% CPU cores busy then you scale again by dividing by 4.

This number is the rPerf's that the virtual machine is actually using.

80:20 rule

Old thinking is that a safe place to run a UNIX server is at 80% CPU utilisation busy and 20% headroom to cover unexpected peaks in the workload (and a little growth in the next year or so). This rather assumes one AIX server is running one workload like a RDBMS.

This results in a server will not need constant monitoring and supervision.

Newer thinking is we can with ever faster computer afford automate monitoring and getting alerting servers going busy.
In Power servers we can now change the number CPU cores and/or memory dynamically and if needed, move a virtual machine to a different server to gain access to even more resources.

Power servers can also be large 240 CPU core and 64 TB of memory so it can run 100's or virtual machines.

In this case, queueing theory tells us we can run servers with much higher utilisation numbers. not ll of the workloads will peak at the same time.

With dynamic resource change as a "get out of jail free card", we can run larger servers with many virtual machines easily at 90% to 95% busy.

This would be a new 90:10 or 95:5 rule.

This is all a judgement call and assumes you know your workloads well to predict - or - you start off with lower numbers and slowly at more workloads or virtual machines to sweat you computer assets.

I hope this helps, Cheers, Nigel | @mr_nmon | IBM retired

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

Thanks so much. I will migrate from p780 to E1080 with PEP 2.0 feature on E1080. It seems to find rperf per core of old machine first, multiply that rPerf per core  to number with number of core used by each LPAR and multiply with cpu utilization and finally use 80:20 or 75:25 rule for safety factor to have white space and the finally number is rperf require on new machine, right?

Actually, I did the same steps but I am not sure I did correct or not. Now, I have more confidence. Tomorrow afternoon I will present this systematic thinking how to derive number of core on new machine to my boss. I also use average utilization for EC and peak utilization for VP.

If you have more advices please and thanks in advance. 

Explaining part 1.

You have to look up the server rPerf value - this covers the whole server with certain set numbers of cores.

Note if your old Power AIX sever is not using a virtual machine but is using the entire servers then you don't need to do this first scale down.

Scale 1:

For example, there may be rPerf numbers for a particular server for 8, 16, 24 and 32 CPU cores.

If you logical partition (virtual machine) does not have one of these four CPUs count then you need to calculate the rPerf.

If your virtual machine has 10 CPU cores then scale by taking the rPerf for 16 CPU cores the divide by 16 and multiply by 10.

Scale 2:

Then, if your virtual machine only ever gets to say 25% CPU cores busy then you scale again by dividing by 4.

This number is the rPerf's that the virtual machine is actually using.

80:20 rule

Old thinking is that a safe place to run a UNIX server is at 80% CPU utilisation busy and 20% headroom to cover unexpected peaks in the workload (and a little growth in the next year or so). This rather assumes one AIX server is running one workload like a RDBMS.

This results in a server will not need constant monitoring and supervision.

Newer thinking is we can with ever faster computer afford automate monitoring and getting alerting servers going busy.
In Power servers we can now change the number CPU cores and/or memory dynamically and if needed, move a virtual machine to a different server to gain access to even more resources.

Power servers can also be large 240 CPU core and 64 TB of memory so it can run 100's or virtual machines.

In this case, queueing theory tells us we can run servers with much higher utilisation numbers. not ll of the workloads will peak at the same time.

With dynamic resource change as a "get out of jail free card", we can run larger servers with many virtual machines easily at 90% to 95% busy.

This would be a new 90:10 or 95:5 rule.

This is all a judgement call and assumes you know your workloads well to predict - or - you start off with lower numbers and slowly at more workloads or virtual machines to sweat you computer assets.

I hope this helps, Cheers, Nigel | @mr_nmon | IBM retired

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

Great explanation Nigel ( as always )
Kritsada - your P780 was putting out approx 10 - 14 rperfs per core and running at SMT-4 ( 4 threads per core ) depending on the exact config. , the E1080 depending on the config is approx 33 - 34 rPerfs per core at SMT-8.   There are other items that have evolved over the generations since POWER7 as well in relation to memory and IO.
I wanted to attach the IBM Power Performance Report to help you evaluate your current hardware and any new equipment.  Here you can look up the exact rPerf values for the hardware in question.  ( the values above are approximate ranges depending on hardware config )

https://www.ibm.com/downloads/cas/K90RQOW8

Thanks so much. I will migrate from p780 to E1080 with PEP 2.0 feature on E1080. It seems to find rperf per core of old machine first, multiply that rPerf per core  to number with number of core used by each LPAR and multiply with cpu utilization and finally use 80:20 or 75:25 rule for safety factor to have white space and the finally number is rperf require on new machine, right?

Actually, I did the same steps but I am not sure I did correct or not. Now, I have more confidence. Tomorrow afternoon I will present this systematic thinking how to derive number of core on new machine to my boss. I also use average utilization for EC and peak utilization for VP.

If you have more advices please and thanks in advance. 

Explaining part 1.

You have to look up the server rPerf value - this covers the whole server with certain set numbers of cores.

Note if your old Power AIX sever is not using a virtual machine but is using the entire servers then you don't need to do this first scale down.

Scale 1:

For example, there may be rPerf numbers for a particular server for 8, 16, 24 and 32 CPU cores.

If you logical partition (virtual machine) does not have one of these four CPUs count then you need to calculate the rPerf.

If your virtual machine has 10 CPU cores then scale by taking the rPerf for 16 CPU cores the divide by 16 and multiply by 10.

Scale 2:

Then, if your virtual machine only ever gets to say 25% CPU cores busy then you scale again by dividing by 4.

This number is the rPerf's that the virtual machine is actually using.

80:20 rule

Old thinking is that a safe place to run a UNIX server is at 80% CPU utilisation busy and 20% headroom to cover unexpected peaks in the workload (and a little growth in the next year or so). This rather assumes one AIX server is running one workload like a RDBMS.

This results in a server will not need constant monitoring and supervision.

Newer thinking is we can with ever faster computer afford automate monitoring and getting alerting servers going busy.
In Power servers we can now change the number CPU cores and/or memory dynamically and if needed, move a virtual machine to a different server to gain access to even more resources.

Power servers can also be large 240 CPU core and 64 TB of memory so it can run 100's or virtual machines.

In this case, queueing theory tells us we can run servers with much higher utilisation numbers. not ll of the workloads will peak at the same time.

With dynamic resource change as a "get out of jail free card", we can run larger servers with many virtual machines easily at 90% to 95% busy.

This would be a new 90:10 or 95:5 rule.

This is all a judgement call and assumes you know your workloads well to predict - or - you start off with lower numbers and slowly at more workloads or virtual machines to sweat you computer assets.

I hope this helps, Cheers, Nigel | @mr_nmon | IBM retired

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

Thanks so much Khun Alan. Except I did with suggestion from Khun Nigel then I added it up with forecast new workload and I also added some additional buffer because when we move existing workload to new machine and it run nearly 90% utilization on old machine then it will run faster on new larger and faster machine so I need to add some more buffer on top. And I also have cloud credit by PEP 2.0 to cover peak load on month end or special event sample Christmas season. Thanks so much again.

Great explanation Nigel ( as always )
Kritsada - your P780 was putting out approx 10 - 14 rperfs per core and running at SMT-4 ( 4 threads per core ) depending on the exact config. , the E1080 depending on the config is approx 33 - 34 rPerfs per core at SMT-8.   There are other items that have evolved over the generations since POWER7 as well in relation to memory and IO.
I wanted to attach the IBM Power Performance Report to help you evaluate your current hardware and any new equipment.  Here you can look up the exact rPerf values for the hardware in question.  ( the values above are approximate ranges depending on hardware config )

https://www.ibm.com/downloads/cas/K90RQOW8

Thanks so much. I will migrate from p780 to E1080 with PEP 2.0 feature on E1080. It seems to find rperf per core of old machine first, multiply that rPerf per core  to number with number of core used by each LPAR and multiply with cpu utilization and finally use 80:20 or 75:25 rule for safety factor to have white space and the finally number is rperf require on new machine, right?

Actually, I did the same steps but I am not sure I did correct or not. Now, I have more confidence. Tomorrow afternoon I will present this systematic thinking how to derive number of core on new machine to my boss. I also use average utilization for EC and peak utilization for VP.

If you have more advices please and thanks in advance. 

Explaining part 1.

You have to look up the server rPerf value - this covers the whole server with certain set numbers of cores.

Note if your old Power AIX sever is not using a virtual machine but is using the entire servers then you don't need to do this first scale down.

Scale 1:

For example, there may be rPerf numbers for a particular server for 8, 16, 24 and 32 CPU cores.

If you logical partition (virtual machine) does not have one of these four CPUs count then you need to calculate the rPerf.

If your virtual machine has 10 CPU cores then scale by taking the rPerf for 16 CPU cores the divide by 16 and multiply by 10.

Scale 2:

Then, if your virtual machine only ever gets to say 25% CPU cores busy then you scale again by dividing by 4.

This number is the rPerf's that the virtual machine is actually using.

80:20 rule

Old thinking is that a safe place to run a UNIX server is at 80% CPU utilisation busy and 20% headroom to cover unexpected peaks in the workload (and a little growth in the next year or so). This rather assumes one AIX server is running one workload like a RDBMS.

This results in a server will not need constant monitoring and supervision.

Newer thinking is we can with ever faster computer afford automate monitoring and getting alerting servers going busy.
In Power servers we can now change the number CPU cores and/or memory dynamically and if needed, move a virtual machine to a different server to gain access to even more resources.

Power servers can also be large 240 CPU core and 64 TB of memory so it can run 100's or virtual machines.

In this case, queueing theory tells us we can run servers with much higher utilisation numbers. not ll of the workloads will peak at the same time.

With dynamic resource change as a "get out of jail free card", we can run larger servers with many virtual machines easily at 90% to 95% busy.

This would be a new 90:10 or 95:5 rule.

This is all a judgement call and assumes you know your workloads well to predict - or - you start off with lower numbers and slowly at more workloads or virtual machines to sweat you computer assets.

I hope this helps, Cheers, Nigel | @mr_nmon | IBM retired

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

When you move your POWER7 LPAR (virtual machine) to Power10 you will need to review the number of cores.
If the VM was running 30 cores then it will need less than 10 on the new server.

Having faster and less CPUs will mean fewer and larger CPU caches = faster memory.

Plus more localised VM's - perhaps your VM will be localised to a single Power10 processor chip and its memory - no more "far" memory access across the server CECs.

Make use of the SMT 8 - Power10 CPU have far stronger CPU core threads.

First guess would be keeping the same memory size but consider tuning that to latter.

If the Power10 has improved disks (perhaps Flash/SSD storage plus larger caches) then disk wait times can be reduced. 

This can reduce in particular batch workload times and backups.

Don't forget to have fun with your new toys, :-)

Thanks so much Khun Alan. Except I did with suggestion from Khun Nigel then I added it up with forecast new workload and I also added some additional buffer because when we move existing workload to new machine and it run nearly 90% utilization on old machine then it will run faster on new larger and faster machine so I need to add some more buffer on top. And I also have cloud credit by PEP 2.0 to cover peak load on month end or special event sample Christmas season. Thanks so much again.

Great explanation Nigel ( as always )
Kritsada - your P780 was putting out approx 10 - 14 rperfs per core and running at SMT-4 ( 4 threads per core ) depending on the exact config. , the E1080 depending on the config is approx 33 - 34 rPerfs per core at SMT-8.   There are other items that have evolved over the generations since POWER7 as well in relation to memory and IO.
I wanted to attach the IBM Power Performance Report to help you evaluate your current hardware and any new equipment.  Here you can look up the exact rPerf values for the hardware in question.  ( the values above are approximate ranges depending on hardware config )

https://www.ibm.com/downloads/cas/K90RQOW8

Thanks so much. I will migrate from p780 to E1080 with PEP 2.0 feature on E1080. It seems to find rperf per core of old machine first, multiply that rPerf per core  to number with number of core used by each LPAR and multiply with cpu utilization and finally use 80:20 or 75:25 rule for safety factor to have white space and the finally number is rperf require on new machine, right?

Actually, I did the same steps but I am not sure I did correct or not. Now, I have more confidence. Tomorrow afternoon I will present this systematic thinking how to derive number of core on new machine to my boss. I also use average utilization for EC and peak utilization for VP.

If you have more advices please and thanks in advance. 

Explaining part 1.

You have to look up the server rPerf value - this covers the whole server with certain set numbers of cores.

Note if your old Power AIX sever is not using a virtual machine but is using the entire servers then you don't need to do this first scale down.

Scale 1:

For example, there may be rPerf numbers for a particular server for 8, 16, 24 and 32 CPU cores.

If you logical partition (virtual machine) does not have one of these four CPUs count then you need to calculate the rPerf.

If your virtual machine has 10 CPU cores then scale by taking the rPerf for 16 CPU cores the divide by 16 and multiply by 10.

Scale 2:

Then, if your virtual machine only ever gets to say 25% CPU cores busy then you scale again by dividing by 4.

This number is the rPerf's that the virtual machine is actually using.

80:20 rule

Old thinking is that a safe place to run a UNIX server is at 80% CPU utilisation busy and 20% headroom to cover unexpected peaks in the workload (and a little growth in the next year or so). This rather assumes one AIX server is running one workload like a RDBMS.

This results in a server will not need constant monitoring and supervision.

Newer thinking is we can with ever faster computer afford automate monitoring and getting alerting servers going busy.
In Power servers we can now change the number CPU cores and/or memory dynamically and if needed, move a virtual machine to a different server to gain access to even more resources.

Power servers can also be large 240 CPU core and 64 TB of memory so it can run 100's or virtual machines.

In this case, queueing theory tells us we can run servers with much higher utilisation numbers. not ll of the workloads will peak at the same time.

With dynamic resource change as a "get out of jail free card", we can run larger servers with many virtual machines easily at 90% to 95% busy.

This would be a new 90:10 or 95:5 rule.

This is all a judgement call and assumes you know your workloads well to predict - or - you start off with lower numbers and slowly at more workloads or virtual machines to sweat you computer assets.

I hope this helps, Cheers, Nigel | @mr_nmon | IBM retired

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

PEP2.0 is a game-changer in metered on-prem cloud space letting you take full advantage of the cores you licensed while having the flexibility cover peaks easily and auto-magically without having to manually activate cores or memory for days.  It really helps right-size for now AND cover spikes AND future growth.

Like Nigel said , storage is another space for performance gains from Flash/SSD to also faster HBAs which will go into next generation PCIe slots,

Enjoy the new iron.

When you move your POWER7 LPAR (virtual machine) to Power10 you will need to review the number of cores.
If the VM was running 30 cores then it will need less than 10 on the new server.

Having faster and less CPUs will mean fewer and larger CPU caches = faster memory.

Plus more localised VM's - perhaps your VM will be localised to a single Power10 processor chip and its memory - no more "far" memory access across the server CECs.

Make use of the SMT 8 - Power10 CPU have far stronger CPU core threads.

First guess would be keeping the same memory size but consider tuning that to latter.

If the Power10 has improved disks (perhaps Flash/SSD storage plus larger caches) then disk wait times can be reduced. 

This can reduce in particular batch workload times and backups.

Don't forget to have fun with your new toys, :-)

Thanks so much Khun Alan. Except I did with suggestion from Khun Nigel then I added it up with forecast new workload and I also added some additional buffer because when we move existing workload to new machine and it run nearly 90% utilization on old machine then it will run faster on new larger and faster machine so I need to add some more buffer on top. And I also have cloud credit by PEP 2.0 to cover peak load on month end or special event sample Christmas season. Thanks so much again.

Great explanation Nigel ( as always )
Kritsada - your P780 was putting out approx 10 - 14 rperfs per core and running at SMT-4 ( 4 threads per core ) depending on the exact config. , the E1080 depending on the config is approx 33 - 34 rPerfs per core at SMT-8.   There are other items that have evolved over the generations since POWER7 as well in relation to memory and IO.
I wanted to attach the IBM Power Performance Report to help you evaluate your current hardware and any new equipment.  Here you can look up the exact rPerf values for the hardware in question.  ( the values above are approximate ranges depending on hardware config )

https://www.ibm.com/downloads/cas/K90RQOW8

Thanks so much. I will migrate from p780 to E1080 with PEP 2.0 feature on E1080. It seems to find rperf per core of old machine first, multiply that rPerf per core  to number with number of core used by each LPAR and multiply with cpu utilization and finally use 80:20 or 75:25 rule for safety factor to have white space and the finally number is rperf require on new machine, right?

Actually, I did the same steps but I am not sure I did correct or not. Now, I have more confidence. Tomorrow afternoon I will present this systematic thinking how to derive number of core on new machine to my boss. I also use average utilization for EC and peak utilization for VP.

If you have more advices please and thanks in advance. 

Explaining part 1.

You have to look up the server rPerf value - this covers the whole server with certain set numbers of cores.

Note if your old Power AIX sever is not using a virtual machine but is using the entire servers then you don't need to do this first scale down.

Scale 1:

For example, there may be rPerf numbers for a particular server for 8, 16, 24 and 32 CPU cores.

If you logical partition (virtual machine) does not have one of these four CPUs count then you need to calculate the rPerf.

If your virtual machine has 10 CPU cores then scale by taking the rPerf for 16 CPU cores the divide by 16 and multiply by 10.

Scale 2:

Then, if your virtual machine only ever gets to say 25% CPU cores busy then you scale again by dividing by 4.

This number is the rPerf's that the virtual machine is actually using.

80:20 rule

Old thinking is that a safe place to run a UNIX server is at 80% CPU utilisation busy and 20% headroom to cover unexpected peaks in the workload (and a little growth in the next year or so). This rather assumes one AIX server is running one workload like a RDBMS.

This results in a server will not need constant monitoring and supervision.

Newer thinking is we can with ever faster computer afford automate monitoring and getting alerting servers going busy.
In Power servers we can now change the number CPU cores and/or memory dynamically and if needed, move a virtual machine to a different server to gain access to even more resources.

Power servers can also be large 240 CPU core and 64 TB of memory so it can run 100's or virtual machines.

In this case, queueing theory tells us we can run servers with much higher utilisation numbers. not ll of the workloads will peak at the same time.

With dynamic resource change as a "get out of jail free card", we can run larger servers with many virtual machines easily at 90% to 95% busy.

This would be a new 90:10 or 95:5 rule.

This is all a judgement call and assumes you know your workloads well to predict - or - you start off with lower numbers and slowly at more workloads or virtual machines to sweat you computer assets.

I hope this helps, Cheers, Nigel | @mr_nmon | IBM retired

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

Thanks so much for both Nigel and Alan to give me your value experiences. I will aware about memory NUMA technology, faster HBA, and I will ask our local IBM about NVMe support on AIX or not, and SMT8 will great support our online workload and I will also consider how large or each LPAR because it will be affected from memory localization.

Thanks again.

PEP2.0 is a game-changer in metered on-prem cloud space letting you take full advantage of the cores you licensed while having the flexibility cover peaks easily and auto-magically without having to manually activate cores or memory for days.  It really helps right-size for now AND cover spikes AND future growth.

Like Nigel said , storage is another space for performance gains from Flash/SSD to also faster HBAs which will go into next generation PCIe slots,

Enjoy the new iron.

When you move your POWER7 LPAR (virtual machine) to Power10 you will need to review the number of cores.
If the VM was running 30 cores then it will need less than 10 on the new server.

Having faster and less CPUs will mean fewer and larger CPU caches = faster memory.

Plus more localised VM's - perhaps your VM will be localised to a single Power10 processor chip and its memory - no more "far" memory access across the server CECs.

Make use of the SMT 8 - Power10 CPU have far stronger CPU core threads.

First guess would be keeping the same memory size but consider tuning that to latter.

If the Power10 has improved disks (perhaps Flash/SSD storage plus larger caches) then disk wait times can be reduced. 

This can reduce in particular batch workload times and backups.

Don't forget to have fun with your new toys, :-)

Thanks so much Khun Alan. Except I did with suggestion from Khun Nigel then I added it up with forecast new workload and I also added some additional buffer because when we move existing workload to new machine and it run nearly 90% utilization on old machine then it will run faster on new larger and faster machine so I need to add some more buffer on top. And I also have cloud credit by PEP 2.0 to cover peak load on month end or special event sample Christmas season. Thanks so much again.

Great explanation Nigel ( as always )
Kritsada - your P780 was putting out approx 10 - 14 rperfs per core and running at SMT-4 ( 4 threads per core ) depending on the exact config. , the E1080 depending on the config is approx 33 - 34 rPerfs per core at SMT-8.   There are other items that have evolved over the generations since POWER7 as well in relation to memory and IO.
I wanted to attach the IBM Power Performance Report to help you evaluate your current hardware and any new equipment.  Here you can look up the exact rPerf values for the hardware in question.  ( the values above are approximate ranges depending on hardware config )

https://www.ibm.com/downloads/cas/K90RQOW8

Thanks so much. I will migrate from p780 to E1080 with PEP 2.0 feature on E1080. It seems to find rperf per core of old machine first, multiply that rPerf per core  to number with number of core used by each LPAR and multiply with cpu utilization and finally use 80:20 or 75:25 rule for safety factor to have white space and the finally number is rperf require on new machine, right?

Actually, I did the same steps but I am not sure I did correct or not. Now, I have more confidence. Tomorrow afternoon I will present this systematic thinking how to derive number of core on new machine to my boss. I also use average utilization for EC and peak utilization for VP.

If you have more advices please and thanks in advance. 

Explaining part 1.

You have to look up the server rPerf value - this covers the whole server with certain set numbers of cores.

Note if your old Power AIX sever is not using a virtual machine but is using the entire servers then you don't need to do this first scale down.

Scale 1:

For example, there may be rPerf numbers for a particular server for 8, 16, 24 and 32 CPU cores.

If you logical partition (virtual machine) does not have one of these four CPUs count then you need to calculate the rPerf.

If your virtual machine has 10 CPU cores then scale by taking the rPerf for 16 CPU cores the divide by 16 and multiply by 10.

Scale 2:

Then, if your virtual machine only ever gets to say 25% CPU cores busy then you scale again by dividing by 4.

This number is the rPerf's that the virtual machine is actually using.

80:20 rule

Old thinking is that a safe place to run a UNIX server is at 80% CPU utilisation busy and 20% headroom to cover unexpected peaks in the workload (and a little growth in the next year or so). This rather assumes one AIX server is running one workload like a RDBMS.

This results in a server will not need constant monitoring and supervision.

Newer thinking is we can with ever faster computer afford automate monitoring and getting alerting servers going busy.
In Power servers we can now change the number CPU cores and/or memory dynamically and if needed, move a virtual machine to a different server to gain access to even more resources.

Power servers can also be large 240 CPU core and 64 TB of memory so it can run 100's or virtual machines.

In this case, queueing theory tells us we can run servers with much higher utilisation numbers. not ll of the workloads will peak at the same time.

With dynamic resource change as a "get out of jail free card", we can run larger servers with many virtual machines easily at 90% to 95% busy.

This would be a new 90:10 or 95:5 rule.

This is all a judgement call and assumes you know your workloads well to predict - or - you start off with lower numbers and slowly at more workloads or virtual machines to sweat you computer assets.

I hope this helps, Cheers, Nigel | @mr_nmon | IBM retired

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks. 

Khun Krisada

What is AIX release you intend to run on the new E1080?   Only AIX 7.3 supports POWER10 compatibility mode.  AIX 7.1 supports only POWER8 compatibility on POWER10 server. AIX 7.2 supports only POWER9 compatibility on POWER10 server.  You also need to ensure certain level of PTF/TR for each of these releases.  More information here :  Power10 Planning and Requirements By Jaqui Lynch at  https://techchannel.com/SMB/07/2022/power10-planning-requirements 

Thanks so much for both Nigel and Alan to give me your value experiences. I will aware about memory NUMA technology, faster HBA, and I will ask our local IBM about NVMe support on AIX or not, and SMT8 will great support our online workload and I will also consider how large or each LPAR because it will be affected from memory localization.

Thanks again.

PEP2.0 is a game-changer in metered on-prem cloud space letting you take full advantage of the cores you licensed while having the flexibility cover peaks easily and auto-magically without having to manually activate cores or memory for days.  It really helps right-size for now AND cover spikes AND future growth.

Like Nigel said , storage is another space for performance gains from Flash/SSD to also faster HBAs which will go into next generation PCIe slots,

Enjoy the new iron.

When you move your POWER7 LPAR (virtual machine) to Power10 you will need to review the number of cores.
If the VM was running 30 cores then it will need less than 10 on the new server.

Having faster and less CPUs will mean fewer and larger CPU caches = faster memory.

Plus more localised VM's - perhaps your VM will be localised to a single Power10 processor chip and its memory - no more "far" memory access across the server CECs.

Make use of the SMT 8 - Power10 CPU have far stronger CPU core threads.

First guess would be keeping the same memory size but consider tuning that to latter.

If the Power10 has improved disks (perhaps Flash/SSD storage plus larger caches) then disk wait times can be reduced. 

This can reduce in particular batch workload times and backups.

Don't forget to have fun with your new toys, :-)

Thanks so much Khun Alan. Except I did with suggestion from Khun Nigel then I added it up with forecast new workload and I also added some additional buffer because when we move existing workload to new machine and it run nearly 90% utilization on old machine then it will run faster on new larger and faster machine so I need to add some more buffer on top. And I also have cloud credit by PEP 2.0 to cover peak load on month end or special event sample Christmas season. Thanks so much again.

Great explanation Nigel ( as always )
Kritsada - your P780 was putting out approx 10 - 14 rperfs per core and running at SMT-4 ( 4 threads per core ) depending on the exact config. , the E1080 depending on the config is approx 33 - 34 rPerfs per core at SMT-8.   There are other items that have evolved over the generations since POWER7 as well in relation to memory and IO.
I wanted to attach the IBM Power Performance Report to help you evaluate your current hardware and any new equipment.  Here you can look up the exact rPerf values for the hardware in question.  ( the values above are approximate ranges depending on hardware config )

https://www.ibm.com/downloads/cas/K90RQOW8

Thanks so much. I will migrate from p780 to E1080 with PEP 2.0 feature on E1080. It seems to find rperf per core of old machine first, multiply that rPerf per core  to number with number of core used by each LPAR and multiply with cpu utilization and finally use 80:20 or 75:25 rule for safety factor to have white space and the finally number is rperf require on new machine, right?

Actually, I did the same steps but I am not sure I did correct or not. Now, I have more confidence. Tomorrow afternoon I will present this systematic thinking how to derive number of core on new machine to my boss. I also use average utilization for EC and peak utilization for VP.

If you have more advices please and thanks in advance. 

Explaining part 1.

You have to look up the server rPerf value - this covers the whole server with certain set numbers of cores.

Note if your old Power AIX sever is not using a virtual machine but is using the entire servers then you don't need to do this first scale down.

Scale 1:

For example, there may be rPerf numbers for a particular server for 8, 16, 24 and 32 CPU cores.

If you logical partition (virtual machine) does not have one of these four CPUs count then you need to calculate the rPerf.

If your virtual machine has 10 CPU cores then scale by taking the rPerf for 16 CPU cores the divide by 16 and multiply by 10.

Scale 2:

Then, if your virtual machine only ever gets to say 25% CPU cores busy then you scale again by dividing by 4.

This number is the rPerf's that the virtual machine is actually using.

80:20 rule

Old thinking is that a safe place to run a UNIX server is at 80% CPU utilisation busy and 20% headroom to cover unexpected peaks in the workload (and a little growth in the next year or so). This rather assumes one AIX server is running one workload like a RDBMS.

This results in a server will not need constant monitoring and supervision.

Newer thinking is we can with ever faster computer afford automate monitoring and getting alerting servers going busy.
In Power servers we can now change the number CPU cores and/or memory dynamically and if needed, move a virtual machine to a different server to gain access to even more resources.

Power servers can also be large 240 CPU core and 64 TB of memory so it can run 100's or virtual machines.

In this case, queueing theory tells us we can run servers with much higher utilisation numbers. not ll of the workloads will peak at the same time.

With dynamic resource change as a "get out of jail free card", we can run larger servers with many virtual machines easily at 90% to 95% busy.

This would be a new 90:10 or 95:5 rule.

This is all a judgement call and assumes you know your workloads well to predict - or - you start off with lower numbers and slowly at more workloads or virtual machines to sweat you computer assets.

I hope this helps, Cheers, Nigel | @mr_nmon | IBM retired

I have plan to migrate existing workload on old Power machine to new power machine with rPerf value and I got a useful url regarding sizing with rPerf but full article about this already remove from IBM site. This is URL that I mention, Sizing with rPerf but Don't Forget the Assumptions (ibm.com). There are briefly how to do sizing but I am not quite get the idea. Below is briefly.

1. Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
2. Add guesstimate of new workloads
3. Add guesstimate of growth
4. Add comfort factor like the old 80:20 rule to cover peaks in work
5. Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
6. Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.

I do not quite clear on first and forth step. Can anybody hint or give me the idea or underlying concept on that why we need to do that on each step sample in the first step why we need to adding up rperf of old machine with scale rating by number of CPU, what is factor 80:20? 

Thanks.