I think that this might be your OTN thread: https://forums.oracle.com/forums/thread.jspa?threadID=2389356

I am not sure how much help I will be able to provide to you. In general, assuming that Oracle is picking up the CPU_COUNT correctly, the CPU_COUNT should take into account any multi-threading/hyperthreading and multiple cores per CPU. Bugs do occasionally happen:
https://supporthtml.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=2820473851313000&id=738114.1 (requires a MOS account)

If the server does in fact have 23 occupied CPU sockets, with each socket containing a dual core CPU that does not support multi-threading/hyperthreading, then the server effectively has 46 seconds of CPU capacity per elapsed second – 165,600 CPU seconds per hour. Keep in mind that just because there are 165,600 CPU seconds of potentially available CPU time per hour, that does not mean that a single session has at its disposal 165,600 CPU seconds per hour. The processes for one or more sessions could still be CPU bound even if the server is not reporting anywhere near 100% CPU utilization.

The PARALLEL_THREADS_PER_CPU parameter is not exactly related to available CPU capacity, but is used in various formulas related to parallel processing:
http://docs.oracle.com/cd/E18283_01/server.112/e17110/initparams187.htm
http://docs.oracle.com/cd/E18283_01/server.112/e16541/parallel004.htm
http://books.google.com/books?id=b3DIkYO2gBQC&pg=PA497

There are AWR scripts that are specific to RAC environments, see the following articles:
http://jonathanlewis.wordpress.com/2011/02/23/awr-reports/
http://orainternals.wordpress.com/2009/12/23/rac-performance-tuning-understanding-global-cache-performance/

I am certain that other readers would be happy to provide additional assistance to you.

This and the other blog about the nice command reminded me of some experiences I had a few years ago. My comments started to be long, so I made a post here:

http://rodgersnotes.blogspot.com/2010/02/oracle-database-tuning-and-being-nice.html

Hope it’s useful.

Charles Hooper has written a number of impressive blog posts in a fairly short space of time (the man is a blogging machine!) but I really wanted to draw attention to one in particular.Fault Quotes 6 – CPU UtilizationWhy? Well I seem to be spending mor…

Thanks for stopping by my blog and leaving such a fantastic follow-up comment with very helpful links. For those reading this blog article, I recommend taking a look at Cary’s “Thinking Clearly”/“Thinking Clearly About Performance” article that he linked to in his comment. I have only read a couple of pages of that article so far, but looking ahead a couple of pages I see a discussion of queuing theory.

My quoted comment was intended to draw a distinction between what the end-user views as a “wait” and what the Oracle session accumulates as a “wait”. (Of course there is also a third potential meaning for wait when talking about a CPU – waiting in the run queue.) In short, my wording in that comment was sloppy. The words “apparently active on the CPU” were intended to include all of the process states that you included in your comment (I think that I would have had trouble listing off all of the different states you supplied) and therefore would not be accumulating time in an Oracle wait event – and I did not make a distinction of which of those would actually increment the CPU time statistic.

In light of your detailed comment, I agree that my statement is not quite right. Unfortunately, my quoted comment could be read in one of several ways.

By the way, thanks for the detailed explanation of how the unaccounted-for time might be used as an indicator of competition for the CPU.