🚀 go-pugleaf

In article <1992Nov17.192804.4410@news.eng.convex.com>
patrick@convex.COM (Patrick F. McGehearty) writes:
Discussion on the C.mmp.
>However, current systems have other methods for getting similar information.
>Other than being a designer preference for "flash" vs "cool", what benefits
>do lots of blinking lights offer, and what should they represent?
>I.e. Do people have suggestions for specific hardware events that might
>be connected to blinking lights on a massively parallel shared memory super?

This is a good question if one stops a moment to really think about it.
The software methods of current monitoring systems tend to be invasive,
more so than people are willing to admit (I have a copy of Viz'92 in front
of me).  I thought about how I would answer this, and it occurred to me that
I wanted to know about the occurence of contention.  But this is wrong.

Event programmability is probably the most important thing you can
build into a diagnostic light system.  I don't think we will know right off
what specific events we will want to watch.  If we did, then we would discover
that raises questions about events the hardware can't detect.

A light system is probably best designed to detect the occurance of events in
a way less invasive than software.  This flexibility is more useful than
software.  Lights have numerous of problems: they are easily overwhelmed,
take up lots of space (real estate), but they might be the answer to
information loss when pushing data thru an Ethernet or other control straw
to a workstation.  But I guess we should be at SC'92 to discuss this.

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Associate Editor, Software and Publication Reviews
  Scientific Programming
  {uunet,mailrus,other gateways}!ames!eugene
Seeking Books to buy:	Bongard, Pattern Recognition
			3 down 1 to go.