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?
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.
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 for letting us know, can you please elaborate on CPU calculation per hr.
Here is our system configuration:
CPU Seconds / Minute
Time Slot (minutes)
Capacity / Slot
Total System Capacity /Slot
Capacity Available after OS
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
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.
Turns to be due to the timezone change, causing a double-logging at the 1AM interval when the clock moved back an hour.