Hi,
Goeff, I would be interested to know how long until you will be able to do real time stats upates (every 6 hours).
I'd like to see a valid node count. This is the number of simultaneous instances of FaD running and may be loosely equated as the number of CPU equivalents. Of course, P4 HT CPU's may show as 2 nodes which is entirely valid.
I've determined an algorithm that should yield a substantially more correct number of CPU's per member number:
Let us define some variables:
Job Start Timestamp = The timestamp for each Job start
Job End Timestamp = The timestamp for each Job end
Member = member number for the Job
#Interval Start = Timestamp of Midnight UTC
#Interval End = Timestamp Midnight UTC + N min.
#member = member number being analyzed
Select count(*) from [dbname] where [dbname]. = #member
and ( [dbname].JobStart < #InvervalEnd )
and ( [dbname].JobEnd > #IntervalStart)
This should yield the number of simultaneous jobs being processed around midnight which should roughly yield the number of "nodes" for any member. If count < 1 then set count = 1. My initial thought is that the interval, N, should be 5 minutes since QUEUE could delay job-to-job transitions by as much as 4 minutes. The potential error here is that if the interval, N, is too small, then any CPU's that complete a job very near our Interval Start may fail to be counted because that CPU may be between jobs during the entire duration of Interval and therefore this would understate the "node" count. The other potential error is that if the interval, N. is too large, then we may select jobs that start after IntervalStart and complete before IntervalEnd which would cause the "node" count to be overstated. In recent history, there have been very few queries that routinely process in 5 minutes or less. In the entire history of the project since Nov '02, there have been several queries that have processed in very short times (some in <20 seconds/job). If such future queries occur, then the calculation would probably be totally borked. Thankfully, such queries have lasted less than a week and in some cases, less than a day.
Now ... adjust the period to reflect a date in the past when most or all of the current queries are completed (IntervalEnd Timestamp = current timestamp - maximuum duration). For example, for a specific node, use the maxium duration for the last week or two to determine when the interval end timestamp should be for the most accurate assessment. Using this approacth the number of nodes will always lag reality but should prove much more accurate than what you currently use.
Steven