what is everyone using to monitor progress??

[MTP]

You know like the old em microscope for G@H?

I have a P4 2.6c @ 3.32G (1022fsb)

You see my o/c success here .

Nothing like all my duallies, but I just retired my VP6 with dual PIII 1G. Showing its age.
Believe it or not this is the only computer I have running right now.

[cygnussphere]

Originally posted by MTP
You know like the old em microscope for G@H?

I have a P4 2.6c @ 3.32G (1022fsb)

You see my o/c success here .

Nothing like all my duallies, but I just retired my VP6 with dual PIII 1G. Showing its age.
Believe it or not this is the only computer I have running right now.

Behind Door #1

Behind door #2

Behind Door #3*









*subliminal pimp of side project

[Jammy]

Does this say what I am using?

Jammy

------------------------------------------------------------
Distributed Folding Windows dfGUI v3.01 Benchmark

Current Generation: 32
Sample Size : 35 structures over 2085 seconds.
Protein Size: 96AA

Structures Per Hour : 60
Structures Per Day : 1450

OS : Windows 2000 MHz: 2100
CPU: AMD Athlon(tm) XP 2600+
Client Switches: -rt
------------------------------------------------------------

[Angus]

I don't think so... we need more info.

[Moogie]

*subliminal pimp of side project

You are smooth!

[magnav0x]

dfGUI v3.01 of course. only the best!

[erk]

Is there a monitoring program that will do a cluster of FreeBSD, MacOS X, and Linux machines?

[bwkaz]

Eventually...

I'm working on the Linux port of dfGUI 3, at the moment. Somewhere back during the DF betas, I added a bunch of code to get it working network-transparently, with a separate dfGUIsrv package that I also wrote at the time. dfGUIsrv was intended to be as portable as I could get it using autoconf/automake, so it *should* have compiled on OSX, BSD, and whatever else. There were fallbacks throughout the code -- if /proc/version didn't exist, for example, it called the uname() function, which should exist on every Unix.

It ended up never getting released (I couldn't figure out the bugs in the thing, and eventually had to move on to doing other junk like homework ), but the code is still there, as is the option in the configure script. If it doesn't take too long to get the rest of the dfGUI 3 features working correctly, I'll probably revisit the issues with dfGUI + dfGUIsrv.

Eventually, this means that you would be able to do one of three things with the Linux dfGUI. You'd install and run dfGUIsrv on each machine you wanted to monitor, of course. Then, you could either connect to each one in turn, using one instance of dfGUI on one Linux box. Or, you could fire up separate instances of dfGUI on that one Linux box -- if you could change the source or the runtime behavior to use a different .dfGUI.rc file for each instance (either change the file's name, or set $HOME to somewhere different for each one), you could get each one talking to each separate machine you wanted to monitor.

Or, and this is probably ideal, I could put another set of tabs in dfGUI, each connecting to a different machine. Tab labels would probably be the IP address of the machine (it won't have any DNS resolving ability that I can see; too hard ), or user-configurable, or something. I'd probably put these tabs at the bottom, with the other tabs (the one in Windows dfGUI) at the top, or reverse it, I don't know yet.

Unfortunately, that means I need some time to sit down and hack away at this program. Working full time does not lend itself well to that, but I think I'll get it. Eventually. dfGUI 3 features are maybe a third done or so at this point, but I haven't gotten hardly any time to work on the thing until noon today.

This also means that you will HAVE to firewall off the port that dfGUIsrv listens on, if you start it in your bootscripts (as root). The protocol that I came up with works a LOT like telnet -- dfGUIsrv just accepts different packet types, and either reconfigures itself, or returns a result, or does something to the DF instance. If someone with malicious intent connects to dfGUIsrv, he could TRIVIALLY tell it to execute "/bin/rm -rf /" as the terminal program, then tell it to launch DF visibly. Bad, bad things WILL happen, as your machine grinds to a halt (remember, it's running as root). I don't want to take out the "visible" option, because if dfGUIsrv is running on the same machine as dfGUI, it's nice to have. It's not too hard to get it to run as non-root, but the user does have to have read access (at least) to the DF directory.

There may also be other projects (DC Monitor? That name springs to mind, if it actually exists...) that do this, though, and do it well, that are working now.

[Dyyryath]

A small Perl app might be good for this. Perl tends to be installed by default on just about everything Unix like these days and it's scripts can be compiled for those platforms that don't have it. I toyed with a similar thing under Genome@Home some time ago. The script installed as a daemon for *nix and as a service for NT and listened on a specific high-number port. At the time, I'd come up with a protocol specifically for that app, but now I'd probably use SOAP or something similar. When a request came along, it simply spit out some basic information about that status of the client. It was a *very* restrictive protocol that wouldn't allow any incoming configuration whatsoever. You made a request, you got the default info, nothing more.