On Friday, March 14, 2003, at 08:47 AM, Jason A. Smith wrote:
I am seeing two major problems:
First, what exactly is the purpose of the new GRID tag? It seems that
it is a mandatory part of the new gmetad system, and more importantly
the authority attribute is mandatory. Is this correct? It
Jason A. Smith wrote:
I do agree with you about making sure that the second gmetad has a
polling interval set to be the same or greater than the interval in the
gmetad that it is getting data from. What is a safe value to use here
anyway? This does help, but not eliminate the problem. It looks
Sorry about my first email, I didn't mean to imply that there was
something wrong with your patch, just that it may have exposed another
problem. I have been thinking about this more and I guess this bug was
only exposed by my change to gmetad to remove the GRID tag from its xml
output so it would
I do agree with you about making sure that the second gmetad has a
polling interval set to be the same or greater than the interval in the
gmetad that it is getting data from. What is a safe value to use here
anyway? This does help, but not eliminate the problem. It looks like I
still get freque
Jason A. Smith wrote:
Which cause the now famous gaps in the rrd graphs when looking at the
hour resolution. The 2.5.2 version of gmetad does not have a problem
getting data from gmetad with the grid tag removed, but 2.5.3 does so I
can only assume it must be related to the new timestamp patch.
I am seeing two major problems:
First, what exactly is the purpose of the new GRID tag? It seems that
it is a mandatory part of the new gmetad system, and more importantly
the authority attribute is mandatory. Is this correct? It appears that
if you setup one gmetad to collect data from another
