PCM and Procurve giving more than 100%

[Les Ligetfalvy]

Just starting to do some load tests on my new Procurve switches and was surprised that I could get more than 100% utilization through them. In fact at one point it was almost 1000% according to PCM+ 1.5 with version 14.1.2.1 of Trafficd.exe. My Fluke OVC tells a more plausible story.

[Les Ligetfalvy]

I wish I had a screenshot of the 1000% but here one over 200%.

[Les Ligetfalvy]

Hmmm... Am I the only person that is having this issue? What makes me so special?

Attached is a screenshot showing over 900%.

[Les Ligetfalvy]

Update:
I was instructed by TAC to remove all traffic settings and to remove the switches from PCM and manually rediscover an add them back in to traffic monitor. So far they are all showing plausible util stats.

My thinking now is that possibly the Trafficd.exe patch (14.1.2.1) that they had me apply for a previous issue may have required this be done. Has anyone else applied the Trafficd.exe patch and not experienced this?

Time will tell.

[Les Ligetfalvy]

Hmmm... maybe I spoke too soon. See 305%attached.

[Les Ligetfalvy]

Well... I got the bad news from HP TAC.

Seems this is a carryover from the old TopTools... when PCM discovers the ports, it locks in the speed in Traffic Monitor, but an offline port may report a different speed than an online port. It then references all utilization from this "discovered" speed so a 10 meg link could report fine, a 100 meg link could report 10X actual and a gig link report 100X actual.

The trick then is to delete everything out of the PCM config and have it rediscover while the ports are online and hope and pray that the link speed does not change.

SHEESH! HP expects us to pay dearly for this product! We should start voting with our wallets!

[Paul Harvey_2 · Accepted solution]

It is using an Access DB to store the information. It is located at C:\Program Files\Hewlett-Packard\PNM\server\data\MTDC on the 1.6 version, it was something similar on 1.5. Just open it in Access (copy out of the directory or shutdown PCM), find the port, it is fairly self-explainitory, change the speed to the correct number. Problem solved.

[Les Ligetfalvy]

This issue persists in PCM+ B.01.607A

[Steve Britt]

These types of problems are primarily caused by the handling of 64-bit octet counters within PCM 1.5 and 1.6. This counter problem will be corrected in PCM 2.0. You should not be seeing such behaviors in the other traffic metrics reported by PCM 1.x (frames, multicasts, broadcasts, and errors).

Note that as it was stated earlier in the thread, PCM is still employing a traffic architecture in which its traffic data collector (trafficd) must be restarted after topology changes in order to pick up changes in link speed, duplex settings, etc. This behavior will ultimately be modified so that trafficd adapts dynamically to such topological changes, but the modifications will be extensive to implement and thus won't make it in the PCM 2.0 time frame. Fortunately, such topological changes should be relatively infrequent and will not cause strange utilizations to appear nearly as often as the counter issue mentioned above.

[Les Ligetfalvy]

Paul Harvey's advice has been spot on and I have been using MS Access to update the link speed whenever I find a discrepancy. I havie been changing out quite a few of my server NICs to gig and find Paul's way much simpler than what HP suggested.

Thanks