bWatch

Robert G. Brown rgb@phy.duke.edu
Sun, 27 Sep 1998 00:20:06 -0400


On Sun, 27 Sep 1998, Jacek Radajewski wrote:

> Robert,
> 
> Unfortunately my Perl is little bit rusty so this is the reason I chose TCL.
> I do agree with you that for this sort of application Perl would have been a
> much better choice.

If you don't mind, and if I ever get the aic7xxx/7890 issue (which
consumes all my non-research, non-teaching, non-family systems
programming energy these days:-) resolved, I may try a port of bWatch
into tkperl.  I've done a couple of tk/tcl -> tkperl ports already;
the tk portions port almost transparently, and the actual logic is
(for me, anyway) so easy to code in C-like perl that it shouldn't
present a problem.  Since perl has regular expressions more or less
built in, parsing nearly anything is fairly easy.

I also have played a bit with BLT (which supposedly ported to tkperl
as well) which "should" allow one to add little bitty dynamic graphs
that, for example, rolldown whenever you press a hostname.  I totally
think that this is a super tool, and you have certainly gone well
beyond what I had hacked together on my own.  I'd like to see if it
can be made extensible at the control layer -- there is a clear need
for an extensible GUI-based toolkit for beowulfen, and (the issue of
TCL or perl aside) the ONLY sane choice for this is Tk.

> a)
> 
> Regarding the colours, the concept is that there are three levels for memory
> usage and CPU loads.  You can set each of the levels/limits and assign a
> colour to it in your .bWatchrc.tcl  file.  For example if you want bWatch to
> display the load in blue if it gets above 1.1 then you : 
> 
> set loadLimit(firstWarning) 1.1
> set colour(firstWarningFG) blue
> 
> if you want this colour to change to green when load reaches 1.5 then :
> 
> set loadLimit(secondWarning) 1.5
> set colour(secondWarningFG) green
> 
> 
>  There is a little bit more explanation in the init.tcl script, but I do
> agree that I should do some more work on the documentation.

I see.  That explains it.  I'll probably double all the CPU load
limits, since all (but one of) my hosts are duals, and a load of 2-2.2
on them is "normal".

> b)
> 
> Original bWatch doesn't auto refresh, but I just received a patch from Erik
> Cumps which will do just that.  I'll have a look at the patch and put it on
> the FTP site.

Great!  This would have been one of my first things to add anyway --
even a five minute granularity is OK, but it takes so long to do a
refresh when you have 20-30 hosts that I get bored and listless
waiting for it to end so I can see where I have an idle host or a
problem.  If I do a perl port, I may really hack things around so that
a bwatchd is spawned on all the hosts that can be tickled to talk back
to the master bWatch program on a real socket -- all those rsh/ssh's
are not very efficient.  I hope you don't mind if I play!

> 
> 
> BTW bWatch is pronounced beowatch  just like Beowulf.
> http://www.sci.usq.edu.au/staff/jacek/bWatch
> <http://www.sci.usq.edu.au/staff/jacek/bWatch>  


Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu