NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/super/1056

Text File | 1992-11-18 | 3.3 KB | 56 lines

Newsgroups: comp.sys.super
Path: sparky!uunet!utcsri!newsflash.concordia.ca!mizar.cc.umanitoba.ca!access.usask.ca!kakwa.ucs.ualberta.ca!myrias!cg
From: [e-mail] (Chris Gray)
Subject: Re: What are people paying for when they by a supercomputer?
Message-ID: <[e-mail]>
Summary: Blinking lights are great!
Organization: Myrias Research Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 18 Nov 92 22:34:13 GMT
Lines: 44

In article <[e-mail]> [e-mail] (Patrick F. McGehearty) writes:
>In article <[e-mail]> [e-mail] (J. Eric Townsend) writes:
>>Blinking lights.  Lots and lots of blinking lights....
>
>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?

I'm a great fan of blinking lights. They can be quite valuable for the system
programmers and for knowledgeable application programmers. On the Myrias
system, we have 6 software-controllable LEDs per processor on a PE tile, and
a few others on the communication card to indicate backplane and intercom
cable activity. The current Myrias kernel uses the 6 LEDs for things like:
executing user code, executing system code, executing in BERR mode, TOD tick,
etc. Special patterns are used when something goes worng. Thus, a quick
glance at the lights can show if the user code has crashed the domain.
Hardware problems can show up as procesors whose lights don't follow the
same pattern as others. Performance bottlenecks can show up similarly -
detecting "stragglers" (tasks that run much longer than all others) is quite
easy. Most of these things can also be done without looking at the lights,
but it is often quicker to just take a quick look. I've seen applications
programmers use the lights to get a feel for the kinds of data motions
(in very rough terms) that a program is causing.

In my own case (programming the IOPs), I use the top 2 LEDs as a simple
blinker in my idle loop - how quickly they blink is a nice indicator of
how busy it is. I've used other lights as simple counters for things like
transaction traffic - even a couple of bits can give you some idea of the
rates, etc. by how fast they blink (you have to pick which bits you want
to see of the real counter). A nice combination of hardware-controlled LEDs
and software controlled ones is VERY good to have.

And last, but not least is hardware diagnostics. If the power-up code does
self-tests, it can display its progress on the LEDs, so that it is easy to
get a clue about what is wrong with something. Our board bring-up people also
used this extensively when bringing the boards up originally.

When a remote site complains that something doesn't work, we have often had
them look at various lights and tell us what they are doing.
--
Chris Gray    Myrias Computer Technologies Inc.   [phone]
    [e-mail]          ...!uunet!myrias!cg