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

[Les Ligetfalvy]

I was really hopeful that this would have been fixed in PCM+ 2.0 but it was not to be. :(

What is worse is that the work-around suggested by Paul Harvey is no longer available.

[Marc Villeneuve_1]

Hi.
So if i folow the tread, it now worth the money to buy PCM Plus if not every options avalable working fine.

I was using TopTools and PCM now. My supervisor told me to analyse if it worth the price. Eck no. It s not cheap to do some little thing more. To much bug... is microsoft having part in HP?!?! LOL

Gona wait till next version befor tinking buying it. I will work with straight PCM till then.

Marc

[Les Ligetfalvy]

Marc,
Well, try not to read too much between the lines. The truth be told, I did not actually buy it as I was testing the beta. I need to walk a tightrope, being careful not to get ostracized from the beta stream for saying the "Emporer has no clothes".

I am still providing feedback to HP and hopefully will work through the issues and shortcomings. Since my last posting, I reconstituted my PCM install as virgin, so time will tell whether this issue still persists. In the meantime, I would like to hear from other 2.0 users that may be experiencing this issue.

As for customers voting with their wallet, it was a comment in a moment of frustration. I realize it is a catch 22... too few customers means less invested in the product. Let us hope that the voice of paying customers is heard.

[Steve Britt]

Hi folks,

I am the PCM traffic architect. I can assure you that we are aware that Traffic Monitor could adapt better to topological and configuration changes, and that this is a longstanding issue (since the TopTools Traffic Monitor) that we definitely intend to address in upcoming PCM releases. I don't intend to be vague with that statement, but we are subject to the same resource and schedule limitations as all of you probably are and so I can't state definitively that such issues will be addressed with 100% certaintly in a given release - but please believe me when I say we know that there are quirks that need to be fixed and that we'll do our best to fix 'em.

I believe I can also safely say, Les, that you will never be ostracized from the PCM beta stream for telling us that "the Emporer has no clothes". While it's true that there isn't a ton of positive chatter that occurs on this forum, that's simply not what the forum is for and so we don't expect lots of pats on the back here. There are a number of us in the ProCurve factory that scan this forum and respond when we believe it will be helpful, including our "official" support folks, and thus I would really like to encourage you all to keep the conversations flowing.

I view issues like this one as useful feedback - obviously there is something here that needs fixing. And the more people that chime in on an issue the higher it raises the priority of that issue for us. As I disclaimed above I cannot guarantee that something will get fixed just because people are clamoring for it here, but the PCM team absolutely uses this kind of feedback as a means of shaping our priorities.

Regards,

Steve

[Les Ligetfalvy]

Thanks Steve, for the feedback. I have been submitting enhancement requests to HP Division and lately sending suggestions directly to the beta stream. One never knows how they are received and whether they get on the to-do list. It is of course, nice to see some aspect of one's suggestions make it into the next version.

[Les Ligetfalvy]

Well... I re-opened the issue with NetHelp, hoping to get at least a decent work-around but to no avail. The only work-around on record with them is to delete the switch from PCM+ and have it rediscover and then reconfigure the Traffic Monitor which IMHO is too drastic.

The simpler work around that Paul mentioned no longer works since PCM2 went to a MySQL database. Does anyone have a workaround that does not require the switch be deleted?

Come on HP, can we kick this up a notch?

[Les Ligetfalvy]

A bit of an update...
I was told this will not be fixed in the pending 2.1 and to quote someone at HP, "This fix will be discussed and will be under investigation for PCM 3.0 (expected late next fall)".

I can connect to the MySQL DB with MyODBC and MS Access, and I can view but cannot edit the port speed entries as I could in 1.6.

Has anyone been able to get further than I could?