FahMon (multi-platform app to monitor various F@h clients)

[EvilAlchemist]

I have 12 clients being monitored by 2.3.4.
Reload time is about 10 seconds for all to complete, which i think is great considering it has to network to 5 systems.

I am having no problems with re-load times (Mine set to 10 min auto-reload)

[uncle_fungus]

well, since my post of 11/16 the CPU spike has gone from 25 secs to 40 secs and the idle memory usage gone from 12/11 to 21/20 Mem/VMem. maybe a little memory leak? during the refresh it's increasing about 9 - 10MB on both Mem and VMem. Still 2.3.4.

I would expect the memory usage to increase slightly when running FahMon for significant periods of time as it appends to the message log. I've got FahMon running on a Windows box here monitoring 4 local clients and MEM/VMEM is 6.8/2.4 and CPU usage is about 4% for less than a second.

[jrweiss]

I haven't been looking too hard at this thread, because I don't run FahMon constantly. However, I just took a look, because I have noticed that 2.3.4 does take much longer to load my clients -- about 15 seconds for GPU + 3xCPU clients over a WiFi-N link that has ~30 Mbps actual throughput. Both machines are XP SP3.

When I start FahMon, pagefile use goes from 1.11 GB to 1.15 GB, and available physical RAM goes from 830484 to 823348. While loading the network clients RAM goes as low as 760792. During that entire time the CPU usage for FahMon is 48-50% -- effectively an entire core of my E6850. Going to the Processes tab, initial memory use is 70,828 + 67,840, dropping to 11,428 + 7,372 after all clients are loaded. Performance is similar when I press F6 to refresh all clients.

So, it appears FahMon IS using significant resources during the reload.

[Hyperlife]

I've gone back to 2.3.2b because the 99% CPU usage during reloads is making my Pentium M laptop unusable for a few seconds at a time.

U_F, let me know if you need any additional info that might help fix this.

[MtM]

The popup only shows when fahmon is actively monitoring or trying to acces a file I think, not been able to reproduce it since fahmon shows them as hung now all the time . When I get a project which runs easier I think it will correctly monitor it again and I'll grab a ss. But I think you're right and it was a windows message informing me about a file io error with a networked resource just wasn't sure before

[MtM]

Saw fahmon reported the ppd for a moment so I tough't I'd stop the vm's and see if came back up. The messagebox alone isn't as bad but fahmon keeps one core fully utilized untill I close the box

[uncle_fungus]

Ah, that error is related to "advanced reload" which checks the modification time first to determine whether or not to reload the whole file. It certainly shouldn't be running at 100% CPU in the background though.

For those of you seeing massive CPU load while reloading, can you give me a ballpark figure for the size of your FAHlogs please. I don't think this is the cause of the load but it might be contributing if the files are large.

[MtM]

fahmon goes into 'not responding' state when it happens untill I close the msgbox. Can't you disable the msgbox and just mark the client as 'disabeld'? It doesn't cause 100% load here ( well it does but on one core only ).

[uncle_fungus]

Yes, but not directly. The error is being generated by windows/wxwidgets rather than by FahMon itself. I can probably fix it by doing additional checks before trying to access the modification time.

Marking the client as disabled doesn't really make sense as that mode is meant to be used for manually preventing FahMon from ever reloading that client. The default state of "inaccessible" should work well enough once I can prevent the error messages from being shown (it works fine if you disable advanced reload).

[MtM]

Yes, but not directly. The error is being generated by windows/wxwidgets rather than by FahMon itself. I can probably fix it by doing additional checks before trying to access the modification time.

Marking the client as disabled doesn't really make sense as that mode is meant to be used for manually preventing FahMon from ever reloading that client. The default state of "inaccessible" should work well enough once I can prevent the error messages from being shown (it works fine if you disable advanced reload).

Yeah true Was only thinking from my own perspective and the disabled would prevent any waisted efforts untill I put the vm's back on. I'll just disable them manually now before I suspend the vm's, that will prevent the error as well.

If you can add just one check to see if the unc is available and if not don't try to acces the last acces time it would be even better but this will work as well.

[jrweiss]

For those of you seeing massive CPU load while reloading, can you give me a ballpark figure for the size of your FAHlogs please. I don't think this is the cause of the load but it might be contributing if the files are large.

Local client: 89 KB
LAN 1: 7.5 KB
LAN 2: 5 KB
LAN 3: 11.5 KB
LAN 4: 3.3 KB

I just reverted to 2.3.2b also, and loading is back to almost instantaneous, even across WiFi...

I never enabled "Advanced Reload," so that's not an issue unless it's the default.

[bollix47]

One thing I've noticed with some of the a2 core WUs is that the unitinfo.txt files grows to a huge size and really brings FAHMON to it's knees. It's especially noticable if the WU is being processed on another computer on my LAN.

The following snipit is from a unitinfo.txt file that is over 172 meg in size.

Code: Select all

Current Work Unit
-----------------
Name: Gromacs
Tag: P2674R2C0G41
Download time: November 20 22:27:00
Due time: November 23 22:27:00
Progress: 1723161618%  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
--More--(0%)

Code: Select all

[03:28:04] Project: 2674 (Run 2, Clone 0, Gen 41)
[03:28:04] 
[03:28:04] Assembly optimizations on if available.
[03:28:04] Entering M.D.
[03:28:10] Will resume from checkpoint file
[03:28:14] ng M.D.
[03:28:20] Will resume from checkpoint file
NNODES=4, MYRANK=1, HOSTNAME=challenger
NNODES=4, MYRANK=0, HOSTNAME=challenger
NNODES=4, MYRANK=2, HOSTNAME=challenger
NNODES=4, MYRANK=3, HOSTNAME=challenger
NODEID=3 argc=19
NODEID=2 argc=19
NODEID=0 argc=19
                         :-)  G  R  O  M  A  C  S  (-:

                   Groningen Machine for Chemical Simulation

                 :-)  VERSION 3.3.99_development_200800503  (-:


      Written by David van der Spoel, Erik Lindahl, Berk Hess, and others.
       Copyright (c) 1991-2000, University of Groningen, The Netherlands.
             Copyright (c) 2001-2008, The GROMACS development team,
            check out http://www.gromacs.org for more information.


                                :-)  mdrun  (-:

Reading file work/wudata_08.tpr, VERSION 3.3.99_development_20070618 (single precision)
NODEID=1 argc=19
Note: tpx file_version 48, software version 56
Making 1D domain decomposition 1 x 1 x 4
starting mdrun '22878 system in water'
249999 steps,    500.0 ps.
[03:28:22] data_08.log
[03:28:22] Verified work/wudata_08.trr
[03:28:22] Verified work/wudata_08.xtc
[03:28:22] Verified work/wudata_08.edr
[03:28:22] Completed 97519 out of 249999 steps  (39%)
[03:36:12] Completed 100009 out of 249999 steps  (40%)
[03:44:00] Completed 102509 out of 249999 steps  (41%)

I tried deleting the unitinfo.txt file but it just recreates it with the same size problem.

[uncle_fungus]

I never enabled "Advanced Reload," so that's not an issue unless it's the default.

That's ok. The only reason it was mentioned was in relation to MtM's issue with Windows generating a modal popup box. This doesn't affect the load issue you're seeing.

One thing I've noticed with some of the a2 core WUs is that the unitinfo.txt files grows to a huge size and really brings FAHMON to it's knees.

This is already fixed in SVN.

[jrweiss]

One thing I've noticed with some of the a2 core WUs is that the unitinfo.txt files grows to a huge size and really brings FAHMON to it's knees.

All mine are 1 KB.

[Nebbuchanezzar]

I am running 2.3.2b under Ubuntu, and I was going to update to 2.3.4. When I

Code: Select all

 sudo apt-get remove fahmon

It returns "no package found"...

I also tried different caps:

FAHMON
FAHMon
FAHmon
FahMon
Fahmon
fahMon
fahmon

none worked...

And it is not in Add/Remove Applications, or when I actually launch synaptic from "System > Administration"

I was told to report/ask here from my home, the MPC forums...

What would you recommend I do so I can get updated to 2.3.4? TYIA!