Before I say anything - I have run the test bench on Matt's tree code,
and I have to say its faster than greased lightning. Really impressive.
On Thursday, March 27, 2003, at 03:03 PM, Steven Wagner wrote:
so.. with the current message method.. this message takes at least 60
+ 60 + 60 + 60 = 240 bytes... and it's flat.
I dont understand how you got 60 bytes for each XDR metric. There is
only one header since the four metrics are grouped. In addition, the
units/type/tmax/dmax/slope will likely be applicable to all metrics in
the group and dont need to be repeated.
Also, how will you accurately transmit float and double metrics in XML?
There are some fundamental problems with floating point accuracy:
something is always lost in a IEEE float -> string translation.
Apples, meet Oranges. Oranges, meet Apples. :) I'm sure a
carefully-thought-out XDR scheme wouldn't provide numbers like that...
I agree with Steve.
World:US:California:Berkeley:UCB:Millennium::mm56:cpu:number
so here is how the URL is read.. i'll call the data between the
delimiters
tokens.
----
1. any token before the double delimiter is considered an
organizational
unit (yes.. i stole that name from LDAP). [btw, no more cluster or
grid
tags!]
If this is just locating a part of an XML tree, why do we need the
"organizational unit" special delimiter? Why not a straight XPath-like
expression.
I am also a believer of consistency in design. The micro structure
(semantics, syntax, addressing) of metrics in a host should be echoed
in the macro structure of grids in the world.
gmetad doesn't simply aggregate though. it summarizes and delegates.
gmetad pushes summary info upstream with links (like hyperlinks) which
point to get where to get more detailed information.
This feature exists right now in the webfrontend 2.5.3 release, except
for the upstream summary view. To get this we will parse incoming XML
at gmetad so it can be queried more efficiently (not just summary
views, but any simple subtree).
Full XPath is not ready or fast enough. I dont believe we need the full
power of regexs to get summary scalability, which is the most juicy
fruit on this tree. I believe a simple interactive gmetad that can
provide summary views and simple subtrees is a good idea. With Matt's
tree code now available, I am confident it wont take much time.
Good that we're thinking about this, g3 looks like it will incorporate
some good ideas.
Federico
Rocks Cluster Group, SDSC, San Diego, CA
