This could be a good Grid demo/monitoring system, if we could display
the real-time load factors on the 4 LBL grid nodes and the ANL cluster.
Depending on how the ifoviz is implemented, we could put the necessary
software on all our Grid nodes to report current load factors. Then the
map could display 4 compute nodes at LBL and the cluster at ANL with
some sort of graphic (bar chart) that indicated loads. When we ran a
demo we should be able to see an increase in the load factor on one of
the nodes. When the other booth ran a demo, both booths would see the
increased use. We can also observe the back ground load at LBN before
starting a computation and choose the least busy node. We may need to
artifically increase the load (and data transfer) imposed by our demo to
make it visible. Or maybe like you are suggesting we would need an
indication that our app is running on a node, separate from the
loadfactor.
We will have one machine/monitor devoted to the DOE Science Grid. When
it is not being actively used for the Fusion or Cosomology demos,
running a Grid Monitoring graphic would be great.
Mary
Kate Keahey wrote:
>
> All,
>
> Below is an excerpt describing the infoviz component for the demo that I
> sent out some time ago. I did not receive any suggestions about what we
> would like to visualize. If you have ideas about either the static or the
> dynamic information you would like to see there, please send me mail by
> tomorrow. My current ideas are
>
> a) dynamic features: visualize control transfer, data transfer (do we need
> to make that difference?), and change of state in an app on a resource
> (computing, not computing)
> b) static features: resources (disk space) and network links between resources
>
> Any other things? It would make sense to visualize the disk space
> especially for the data server, would it make sense to visualize other
> things (such as os, processor type, etc)? If you want to have input into
> this, now is the time to send me mail.
>
> >2) Infoviz component. There is a person in our group who is currently
> >working with the Futures Lab on developing such component. The component
> >will visualize computation and data transfer across the map of the US. It
> >is still being designed but chances are it will be something like this.
> >The moving data will be visualized as a series of dots moving between two
> >destinations (faster for faster bandwidth), the computing resources will
> >be say represented by some static information (such as number of
> >processors, available memory, etc), and the computation itself will be
> >mapped to some of those nodes. At least this is the current thinking, this
> >is very much work in progress which means that (1) it is not there yet (2)
> >we could have some input. Let me know if you have suggestions/ideas; not
> >all of them can be implemented (at this point) since this component will
> >be shared across many demos and has to accommodate the most popular set of
> >functionality, but I will try. The interface to this component is a bit in
> >a flux right now, but it will probably be something along the lines of a
> >message periodically sending information (during a transfer) about how
> >much data was sent. So once we have something working and also once the
> >interface is better defined we can think about integrating it into our
> >demo. At this point, it seems like the esiest way to do that would be to
> >use GridFTP (instead of Globus io) for data transfer. Doing this would
> >probably entail using the new version of Globus, etc,so there are some
> >issues here we should discuss.
>
> __________________________
> Dr. Kate Keahey
> Math & Computer Science Div.
> Argonne National Laboratory
> Argonne, IL 60439, USA
> (630) 252-1673
>
> ===============================================================================
>
> This message was sent to the SciDAC National Fusion Collaboratory (NFC)
> workers list nfc-sc01. Visit the Collaboratory at
> <http://www.fusiongrid.org/>.
>
> To unsubscribe from this list, please send a message to
> majordomo@fusion.gat.com with the following text in the *body* of the
> message: unsubscribe nfc-sc01
>
> David P. Schissel: <schissel@fusion.gat.com> <http://fusion.gat.com/~schissel/>
-- --------------------------------------------------------------------- Mary R. Thompson <MRThompson@lbl.gov> Distributed Security Research Group (510) 486-7408 Lawrence Berkeley National Lab http://www-itg.lbl.gov/~mrt ----------------------------------------------------------------------===============================================================================
This message was sent to the SciDAC National Fusion Collaboratory (NFC) workers list nfc-sc01. Visit the Collaboratory at <http://www.fusiongrid.org/>.
To unsubscribe from this list, please send a message to majordomo@fusion.gat.com with the following text in the *body* of the message: unsubscribe nfc-sc01
David P. Schissel: <schissel@fusion.gat.com> <http://fusion.gat.com/~schissel/>
This archive was generated by hypermail 2.1.1 : Fri Feb 08 2002 - 13:34:29 PST