Wednesday, March 5, 2008

ITM 5.1.2 FP05 Changes to DMXCpu

Before I tell you about the change I have a funny and somewhat ironic story to tell you on this one.

A little over three years ago I worked on the IBM Tivoli Monitoring Version 5.1 Advanced Resource Monitoring Redbook. During my research on the Redbook I found some significant anomalies in the way DMXCpu was reporting its CPU times. I found that when ever there was a high wait i/o I would get huge discrepancies between what the DMXCpu provider was calculating for CPU percentages and what I was seeing from TOP. After further research it appeared that the DMXCpu provider was not taking into account wait i/o when calculating cpu idle time and it appeared that TOP was. So whenever there was a high wait i/o on a box the DMXCpu provider and TOP would show different results. Upon further research I discovered that it was a common practice on Solaris to ignore wait i/o and assume it as a subset of cpu idle time (especially on an MP). As most Tivoli old timers know, a lot of the original Tivoli code was primarily developed and tested on SUN boxes. Therefore, at the time I made the assumption that the descrepency might have been a hold over logic from the old DM classic code (i.e., ignoring the wait i/o). I turned over my findings to IBM at that time and told them this issue needed further research. If you have been following the TME 10 list server over the last few years you have probably seen a lot of confusion about discrepancies in DMXCpu and other tools.

Now, here's the funny part, three years latter the ITM 5.1.2 FP05 DMXCpu resource model now includes wait i/o time as a property. I am also assuming they are now calculating the idle time similar to the way TOP always has (I haven't had time to test this yet). Now for the ironic part, now that Tivoli includes wait i/o time in DMXCpu Sun now forces wait i/o to zero on Solaris 10. Sun decided that since there has been so much confusion over the years due to wait i/o (especially on MPs) it would be easier to just force it to a zero value.

If anyone has a chance to test the new FP05 on an MP against TOP I would be real interested to know your results.

John Willis

No comments: