Have you ever tried to figure out ahead of time how many CPU seconds an application would require after upgrading to a new hardware platform? I talked about one approach to solving this problem at the recent Partners Conference in San Diego, and would like to share my approach with you.
First, there a couple of assumptions we need to agreed upon when it comes to converting CPU seconds from one node generation to another:
So when it comes to making a CPU-second conversion you will want to consider both the power differences of the nodes, and any difference in the number of CPUs per node.
Most of us are used to CPU seconds, like everything else around us, becoming more powerful with each new generation. But that has changed recently with some of the new chip architectures. With technologies such as multi-core designs and hyper-threading, in which multiple cores exist within each chip, inter-core communication and sharing reduces the strength of each individual CPU second.
It is important to not jump to the conclusion that this somehow means a step backwards to weaker nodes. As long as you are combining a greater number of CPUs (cores) on the node, even if each is slightly weaker, their larger numbers will suffice the make the node more powerful. More CPUs per node make for more powerful nodes, even with less powerful CPUs.
An important player in doing a translation of CPU seconds across different node types is TPerf. The different TPerf ratings of the two nodes, the old, slower node, and the new, faster node, can help to do the conversion. TPerf is a measure of Teradata node throughput potential which uses the 5100M from 1998 as a baseline. If your node’s TPerf rating is 5, it means your node is 5 times more powerful than the 5100M node. TPerf is an indicator, not a predictor of performance change.
Standard TPerf, the one that most of you are familiar with, represents the entire node, including the disk sub-system. There is a variant of TPerf, called “Baseline Uninhibited” TPerf, that represents raw CPU power only. Because it focuses solely on CPU differences, it is best to use baseline uninhibited TPerf when converting CPU seconds from one node type to another.
Below is a graphic that illustrates the two steps you need to take to do this CPU-seconds conversion. This example assumes that the number of CPUs per node are the same. However, both Step 1 and Step 2 below factor in the number of CPUs so that we can build a formula that will be useful in cases where the number of CPUs might be different. This example below uses artificial TPerf numbers just for the sake of making the math easy. Basically, what is being shown is that if you new node has double the TPerf rating and the same number of CPUs, an application’s CPU seconds will be cut in half on the new platform. With twice the power, it takes ½ the effort to do the same work.
This next graphic uses the same example, but combines step 1 and 2 into a single formula, by moving some of the factors around. Here we have produced a single formula that can be used when converting CPU seconds from one node type to another.
This next graphic takes this formula and applies it to actual nodes types with real-world TPerf numbers, the 5400 and the 5450. Both of these node types have the same number of CPUs per node.
Since we already have a formula with some flexibility built in, we can see how it works in the case where the number of CPUs has increased in the new node type. In the example below, CPU seconds from an application running on a 5550 node are converted to CPU seconds for the same application running on a 5600 node.
Notice in the example shown above that the number of CPU seconds is somewhat greater on the new node type. This is due to the increased numbers of CPUs on the 5600 and the sharing overhead that accompanies it. Each CPU second does slightly less work, but since there is many more of them, the node itself is more powerful and the work will be accomplished in a shorter time.
Keep in mind that advancing technologies can introduce some variation in post-upgrade CPU usage numbers. TPerf by itself can only provide a ball-park estimate, and is only a starting point. Operating system changes can result in CPU being handled or reported differently. Shifts in how the node is architected can also be a factor in CPU usage.
But hopefully, this approach to converting CPU seconds can be a starting point for simple extrapolations and assessments when you are preparing for, or are in the midst of, a hardware change.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.