Database
Enthusiast

## Formulae to calculate total available CPU Seconds per Day

Hi All,

we recently migrated to 6800 system and implemented PMCOD 75%.

I am using following formulae for available CPU Cycles in 6800 system.

So estimated total available CPU seconds/day is #Nodes*#CPUs*Seconds/day = 4*32*86,400 CPU Seconds/day . i.e. 11,059,200 CPU Seconds/day.

As per my understanding, 75% PMCOD means CPU will theoretically be 33% higher compared to no COD.  It is nothing but, the access to CPU is reduced by internal mechanisms that stop the CPU from doing work for a percent of the time for each core on the node. So CPU Utilization recorded in DBQL will be higher by an amount that represents the inverse of the PMCOD level.

So bottom line is, the total available CPU cycles/day won’t change but with COD, CPU utilization by the user will be higher as compared to no COD.

Is my understanding correct or is it little more complicated?

8 REPLIES
Teradata Employee

## Re: Formulae to calculate total available CPU Seconds per Day

A 6800H node has two E5-2697 V3 processors with 14 cores each and 2 pipelines per core. That would make your multiplier 56 per node not 32.

Some of those CPU cycles will be consumed by the OS, so typically we might figure 80% available to the database.

Yes, with PMCOD there are just as many CPU seconds as on a node with no COD, but each CPU second can do less work - so for the same workload the apparent CPU utilization will be higher.

Enthusiast

## Re: Formulae to calculate total available CPU Seconds per Day

Thanks, Fred.

I got the response from Teradata PS team. Just for everyone sake, i am providing the details as shown below

Here is the formulae used to calculate estimated total available CPU seconds/hr:

Number of Nodes (4) * Number of cores per node(16) * PMCOD(0.75) * 3600 (60 secs*60 mins) * .80 (capacity available after OS) = 138240 seconds available per hour.

Thanks,

Harsha.

Teradata Employee

## Re: Formulae to calculate total available CPU Seconds per Day

That calculation may be correct for some system, but definitely not for a 6800 nor for PMCOD

Enthusiast

## Re: Formulae to calculate total available CPU Seconds per Day

Hi Fred,

Thanks for letting us know, can you please elaborate on CPU calculation per hr.

Here is our system configuration:

 Node Model 6800 # Nodes 4 CPU's/Node 16 AMPs/Node 42 CPU Seconds / Minute 3,840 Time Slot (minutes) 60 Capacity / Slot 230400 Total System Capacity /Slot 230400 Capacity Available after OS 80% Capacity Multiplier 0.75 Net Capacity/Slot 138,240
Enthusiast

## Re: Formulae to calculate total available CPU Seconds per Day

Hi Fred,

Can you please respond to my question.

Teradata Employee

## Re: Formulae to calculate total available CPU Seconds per Day

The 6800H has 2 processors x 14 cores x 2 hyperthreads = 56 "virtual CPUs" per node, unless some cores are disabled intentionally.

PMCOD capacity multiplier is important for understanding CPU consumption, but it should not be part of the "available CPU seconds" calculation. As you said above, it means the measured consumption will be 33% higher than the CPU required on a system with no COD.

Have you checked the ResUsage data, e.g.

select NodeID, cast(TheTime as INTEGER)/10000 as TheHour, count(distinct CpuId) as CpusPerNode,

sum(CPUIdle+CPUIoWait+CPUUServ+CPUUExec)/100 as CpuSecsPerHour

from dbc.ResScpuView where TheDate = current_date - 1

group by NodeID, TheHour order by TheHour, NodeID

Teradata Employee

## Re: Formulae to calculate total available CPU Seconds per Day

Hi Fred,

What would cause the CPUSecsPerHour to double?  I extracted a monthly report and saw an unusual spike for one day at this hour. It's a 2800 system.

 NodeID TheHour CpusPerNode CpuSecsPerHour 102 0 56 201,602.80 105 0 56 201,602.80 102 1 56 403,206.16 105 1 56 403,206.16 102 2 56 201,602.24 105 2 56 201,602.24 102 3 56 201,602.80 105 3 56 201,602.80 102 4 56 201,602.24 105 4 56 201,602.24

Thanks,

Jas

Teradata Employee

## Re: Formulae to calculate total available CPU Seconds per Day

Turns to be due to the timezone change, causing a double-logging at the 1AM interval when the clock moved back an hour.