Clarification on Cacti Device Fields

[Amag]

This should be a simple question to answer, but I can't seem to find any posts/documentation explaining it.

Under the devices link, we have the columns of
Current (ms)
Average (ms)
Availability

What are we measuring exactly? Is this the time it takes for Cacti to ping the device, or the amount of time that it takes for the poller to run against the device?

[rony]

The amount of time that it takes Cacti to ping, either UCMP or UDP ping the device.

[Amag]

Yuck. That's what I was hoping it WASN'T. I'm receiving times that range from 30-100ms on devices that are on the same LAN. Obviously, I'm not asking for LAN troubleshooting, as I'm quite capable of doing that.

Is the "ms" reading milliseconds or microseconds?

Can you shed some light on how the ping works exactly? That is, is device #1 pinged first, then queried via SNMP for OIDs, then device #2, device #3, etc? That is, could device #100 theoretically be behind device #1 in ms due to the time it takes Cacti to process?

What's interesting is if I ssh onto the Cacti server and ping the devices, they respond in <1ms (milliseconds) (as expected).

Thanks.

[rony]

ICMP response times vary to UDP response times. If the device is busy, you will see higher UDP response times before you see higher ICMP times. Also, a better test would be to increase your ICMP packet size to just smaller then MTU and see what your response time is.

Btw, milliseconds. Micro would be noted by a "u".

[Amag]

Rony,

Thanks for the prompt reply. I've been banging my head over this issue for a few weeks.

The devices in question are Cisco 6500s, so they are not particularly busy due to the large processrs on them.

What's odd is if I ping the 6500 from the linux box itself, the response times are as expected. It's only with Cacti where I get horrible response times.

Where would I increase the ICMP packet size in Cacti? My MTU is standard Ethernet (1500). Is this something done on Cacti itself or on the linux kernel? Either way, could you explain how I would do that? I'm not sure why that would improve Cacti's response time though, as I'm seeing valid times using the CLI ping.

Note, I've experienced this issue on several different Cacti installations. I have over 100 devices and the server currently running Cacti is an HP 360 dual core.

[rony]

When I refer to increasing the packet size, I'm refering to the ping command. Use the man page to get the exact syntax for it. I do know you will have to be root to do it.

[Amag]

Rony -

I believe you're referring to ping ipaddr -s xxxx (e.g., ping 10.10.10.1 -s 1400 for a continuous 1400 byte ping). (FYI, in Windows its ping -t -l 1400).

I'm not sure how this ties into Cacti. Cacti should be utilizing the default ping command if we choose ICMP (instead of a UDP packet). This is 56 bytes + 8 bytes for the ICMP header. Consequently, Cacti is sending a 64 byte packet to a destination and recorinding the response time, correct?

For instance, Cacti reports a 72.2ms response time for device 12SVR. If I use the Linux CLI and ping the same device, I get anywhere between 1-6ms for a response time.

I'm not sure where to go with this one...

[rony]

There is no place to go with this one.

What is your root issue with these values?

[Amag]

The root issue is that the values are incorrect -- grossly. If Cacti is going to provide statistics on the device page, I'd like for them to be correct or be able to be disabled. I hate providing my users with incorrect data, as it leads to a plethora of other issues.

Can you provide this thread with a brief explanation of how the Cacti code goes about checking device response time? That is, how many pings are sent out, they wait x amount of seconds for a response and then record the value?

Thanks!

[lbaskball45]

bump!

I was hoping his question would be answered as I am having similar issues.