Actually, the only way I was able to stop the line wrapping in the cluster view was to add the nowrap attribute to some of the table elements. I think it was trying to vertically stretch out that nested table because the right side had the 4 plots arranged in a 2x2 grid causing that table cell to be vertically longer than the left side needed to be.
Also, I noticed that the Avg Load percentages are derived from the number of hosts up. I think it would be more accurate to use the number of CPUs instead, at least if it is going to be reported as a percentage instead of an absolute value. ~Jason On Fri, 2003-05-23 at 15:45, Jason A. Smith wrote: > Very nice, I like this a lot better. > > I noticed another minor thing. The table on the left side of the > cluster & meta view plots is not handled in the same way. In the web > browser that I am using, this causes the CPU Totals and Avg Load > information to be wrapped on the cluster view making it harder to read. > I looked at the code and found that they are even handled differently in > the way the code uses the templates. Perhaps this should be changed to > be more consistent. To find what I am talking about, just look for > cluster_load in the files and compare how meta_view.php/meta_view.tpl & > cluster_view.php/cluster_view.tpl work for that table. The meta_view > template was setting the class to footer causing it to use a smaller > font and not line wrap on my browser. > > Also, what is this new pie chart thing, it doesn't seem to work for me? > > ~Jason > > PS. What are the future plans for the port 8652 interface? Will it only > be used by the webfrontend or will gmetad use it also? > > > On Fri, 2003-05-23 at 13:22, Federico Sacerdoti wrote: > > I just checked in changes that incorporate many of your suggestions. I > > still need to solve the overall summary chatter, but I have found the > > bug (in gmetad - thread synchronization) and I am working on the fix. > > > > But this webfrontend works well. It puts the dead nodes on top of the > > cluster view, and tells when they last sent a heartbeat. The graphs are > > bigger, with the "now" value, etc. > > > > -fds > > > > On Monday, May 19, 2003, at 08:36 AM, Jason A. Smith wrote: > > > > > I just tried the latest gmetad & webfrontend from cvs to test out the > > > improved page load speed and other features and have a few comments: > > > > > > First, the grid summary totals appear to be messed up in gmetad. Both > > > the rrds and xml data constantly display/report fluctuating numbers. > > > Is > > > this a known bug, have you seen this in your tests? > > > > > > I like the new more compact cluster view that gets rid of the colored > > > node icons and just colors the plots instead, but I think the small > > > graphs are a little too small. They are so small that often rrdtool > > > doesn't even add any labels to the horizontal & vertical axis, and the > > > actual plot area takes up a very small portion of the total image area. > > > Also, I think removing the legend is a mistake, it was useful for us to > > > be able to see the value "now". Sometimes one node goes out of control > > > reporting loads over 100 and setting the vertical range to accommodate > > > the highest max value means the other plots are useless, especially > > > with > > > no "now" value displayed. > > > > > > I think dead nodes should be shown at the top of the cluster list, not > > > the bottom, because it is important info, just like high load is. If > > > you have a large cluster then you don't want to have to scroll all the > > > way to the bottom to see if there are any dead nodes. For dead nodes, > > > it would also be nice if the last reported time was shown without > > > having > > > to go to the node view, and shown as a human readable timestamp. The > > > last heartbeat doesn't seem to work when the node is listed as dead, I > > > thought it worked before. Also, the text table showing the cpu and > > > load > > > averages is often too narrow making it hard to read when it wraps > > > repeatedly. This seems to vary depending on the browser use, I tried > > > the old netscape and mozilla. > > > > > > What is required for the pie charts? They don't work for me at all. > > > > > > One last minor comment, why was the default_range changed to a day? I > > > think an hour is much more useful and don't think the page needs to > > > reload itself every 300 seconds if the default range is set to 24 > > > hours. > > > > > > ~Jason > > > > > > PS. What is wrong with sourceforge lately, I keep getting broken > > > connections when trying to access their cvs server? > > > > > > > > > -- > > > /------------------------------------------------------------------\ > > > | Jason A. Smith Email: [EMAIL PROTECTED] | > > > | Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 | > > > | Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 | > > > | Upton, NY 11973-5000 | > > > \------------------------------------------------------------------/ > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: If flattening out C++ or Java > > > code to make your application fit in a relational database is painful, > > > don't do it! Check out ObjectStore. Now part of Progress Software. > > > http://www.objectstore.net/sourceforge > > > _______________________________________________ > > > Ganglia-developers mailing list > > > Ganglia-developers@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > > > > > Federico > > > > Rocks Cluster Group, San Diego Supercomputing Center, CA -- /------------------------------------------------------------------\ | Jason A. Smith Email: [EMAIL PROTECTED] | | Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 | | Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 | | Upton, NY 11973-5000 | \------------------------------------------------------------------/
