I know one vendors product IDERA (Diagnostic Manager) that makes use of this legacy SP.. IMHO it can provide inaccurate values, more evident on SMP systems, One issue is that if the @@CPU_BUSY function once it reaches a limit (134217727) it never increments higher - sp_monitor uses @@CPU_BUSY system function in its code

(review results stored in master.spt_monitor)

lastrun cpu_busy

2010-03-04 13:21:29.400134217727

Note: other @@ functions return higher numbers ? (so appears to be specific issue with that system function.)

Generally if I'm using SS 2005+ I will definetly want to make be using DMVs, these will provide more accurate

Try the following example. (very usefull !) .try comparing these against your perfmon counters

(Gives you a metrics @ minute intervals )

DECLARE @ts_now BIGINT

SELECT @ts_now = cpu_ticks / CONVERT(FLOAT, cpu_ticks_in_ms) FROM sys.dm_os_sys_info

SELECT record_id,DATEADD(ms, -1 * (@ts_now - [timestamp]), GETDATE()) AS EventTime,

SQLProcessUtilization,

SystemIdle,

100 - SystemIdle - SQLProcessUtilization AS OtherProcessUtilization

FROM

(

SELECT

record.value('(./Record/@id)[1]', 'int') AS record_id,

record.value('(./Record/SchedulerMonitorEvent/SystemHealth/SystemIdle)[1]', 'int') AS SystemIdle,

record.value('(./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization)[1]', 'int') AS SQLProcessUtilization,

TIMESTAMP

FROM (

SELECT TIMESTAMP, CONVERT(XML, record) AS record

FROM sys.dm_os_ring_buffers

WHERE ring_buffer_type = N'RING_BUFFER_SCHEDULER_MONITOR'

AND record LIKE '% %'

) AS x

) AS y

ORDER BY record_id DESC