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

[TheWolf]

I had noticed some drop in PPD on some of my rigs that run for days on end without a reboot.
I didn't know about the CPU usage possible bug till now, so I'm not sure if this was the loss in PPD for those rigs.
I did notice after a close of the programs & reboot & restart that my PPD would go back at full speed for days before I would have to do a reboot to fix the loss in PPD again.

I will be sure to post if this looks better, but I'm sure it will be some days before I will know for sure.

[Pette Broad]

Working well here, correct 370x status and sporadic crashes look to have ceased.


Thanks,

Pete

[toTOW]

I see an issue on the webapp html file (look at the credit column) :


Is it normal that both French and English are mixed ?

[uncle_fungus]

I see an issue on the webapp html file (look at the credit column) :


Is it normal that both French and English are mixed ?

The credit columns is just a typo in the template file. It has "points" written after the template macro.

The column titles are untranslated because I need to write some extra template macros. I'll fix this for the final release.

Edit: Fixed.

[francois]

Thanks!
The ticket 76 seems to have been resolved too, at least here at work.
FahMon doesn't crash anymore when the wallpaper is changed and icon background transparency is set!

Will try tonight at home and report later.

Best regards,
François

Works great at home too!
Thanks!

[Hyperlife]

It looks like the effective rate calculation is off by quite a bit. On one of my machines, a p3907 is being calculated with a ridiculously low PPD:

Code: Select all

 Project : 3907
 Core    : Double Gromacs B
 Frames  : 100
 Credit  : 310


 -- Accounting --

 Min. Time / Frame : 10mn 10s  - 439.08 ppd
 Avg. Time / Frame : 10mn 11s  - 438.36 ppd
 Cur. Time / Frame : 10mn 13s  - 436.93 ppd
 R3F. Time / Frame : 10mn 11s  - 438.36 ppd
 Eff. Time / Frame : 2h 12mn 15s  - 33.75 ppd

The log shows that there's been no downtime on this project:

Code: Select all

[14:24:40] - Preparing to get new work unit...
[14:24:40] + Attempting to get work packet
[14:24:40] - Will indicate memory of 1014 MB
[14:24:40] - Connecting to assignment server
[14:24:40] Connecting to http://assign.stanford.edu:8080/
[14:24:40] Posted data.
[14:24:40] Initial: 40AB; - Successful: assigned to (171.64.122.88).
[14:24:40] + News From Folding@Home: Welcome to Folding@Home
[14:24:40] Loaded queue successfully.
[14:24:40] Connecting to http://171.64.122.88:8080/
[14:24:41] Posted data.
[14:24:41] Initial: 0000; - Receiving payload (expected size: 345837)
[14:24:42] - Downloaded at ~337 kB/s
[14:24:42] - Averaged speed for that direction ~422 kB/s
[14:24:42] + Received work.
[14:24:42] Trying to send all finished work units
[14:24:42] + No unsent completed units remaining.
[14:24:42] + Closed connections
[14:24:42] 
[14:24:42] + Processing work unit
[14:24:42] Core required: FahCore_7b.exe
[14:24:42] Core found.
[14:24:42] Working on Unit 09 [January 25 14:24:42]
[14:24:42] + Working ...
[14:24:42] - Calling 'FahCore_7b.exe -dir work/ -suffix 09 -checkpoint 30 -service -forceasm -verbose -lifeline 1432 -version 600'

[14:24:42] 
[14:24:42] *------------------------------*
[14:24:42] Folding@Home Double Gromacs Core B
[14:24:42] Version 1.04 (Fri Aug 10 16:46:39 PDT 2007)
[14:24:42] 
[14:24:42] Preparing to commence simulation
[14:24:42] - Assembly optimizations manually forced on.
[14:24:42] - Not checking prior termination.
[14:24:42] - Expanded 345325 -> 1203089 (decompressed 348.3 percent)
[14:24:42] 
[14:24:42] Project: 3907 (Run 4124, Clone 1, Gen 1)
[14:24:42] 
[14:24:42] Assembly optimizations on if available.
[14:24:42] Entering M.D.
[14:24:49] Working on Lig in water
[14:24:49] Completed 0 out of 500000 steps  (0)
[14:24:49] Extra SSE2 boost OK
[14:34:56] Completed 5000 out of 500000 steps  (1)
[14:45:08] Completed 10000 out of 500000 steps  (2)
[14:55:18] Completed 15000 out of 500000 steps  (3)
[15:05:31] Completed 20000 out of 500000 steps  (4)

2.3.1 is reporting the effective time is in the high 800PPD range (due to the doubling error, of course).

[uncle_fungus]

Is the download date shown on the WU Information panel correct for this WU?

[Pette Broad]

Several issues today. On restart this morning I had no machine panel and I had difficulty getting it to maximise from the icon on the taskbar. Also, several of my machines had missing or incorrect locations, some kind of data corruption I guess. I deleted the prefs.dat file and everything went back to normal. Then I picked up a P2582 and after a few seconds I had a crash and from then on it crashed at launch no matter what I did . Went back to 2.3.1 and all is well again.

Pete

[Hyperlife]

Is the download date shown on the WU Information panel correct for this WU?

No, it's way off. The panel says it was downloaded almost 12 hours ago, when in reality it was downloaded just under 4 hours ago.

I just tried to manually set the time zone in Preferences, and that fixed the download time.

Wait, this is weird. I quit out and start again, and the time goes back to UTC, even though I still have it manually set. Then when I uncheck the manual time box, it's correct again. And other clients are still off by 8 hours.

I checked all my other clients before setting the time manually, and the download time was off by 8 hours on all of them. I'm in California (UTC-8).

[uncle_fungus]

Several issues today. On restart this morning I had no machine panel and I had difficulty getting it to maximise from the icon on the taskbar. Also, several of my machines had missing or incorrect locations, some kind of data corruption I guess. I deleted the prefs.dat file and everything went back to normal. Then I picked up a P2582 and after a few seconds I had a crash and from then on it crashed at launch no matter what I did . Went back to 2.3.1 and all is well again.

Pete

Not sure about the data corruption, but the instant crash is due to this: viewtopic.php?p=7370#p7370 which has been fixed already.

I'll probably put out a beta2 in the not-too-distant future to make sure of this.

Is the download date shown on the WU Information panel correct for this WU?

No, it's way off. The panel says it was downloaded almost 12 hours ago, when in reality it was downloaded just under 4 hours ago.

I just tried to manually set the time zone in Preferences, and that fixed the download time.

Wait, this is weird. I quit out and start again, and the time goes back to UTC, even though I still have it manually set. Then when I uncheck the manual time box, it's correct again. And other clients are still off by 8 hours.

I checked all my other clients before setting the time manually, and the download time was off by 8 hours on all of them. I'm in California (UTC-8).

OK, well the download time as stored in the queue is in UTC, so it needs to be converted to your local time to show correctly.
I find that the internal wxWidgets timezone converter is a load of rubbish hence the manual setting. I always have it enabled (I'm in UTC).

When you adjusted the timezone manually did it correct the effective frame time?

[Hyperlife]

OK, well the download time as stored in the queue is in UTC, so it needs to be converted to your local time to show correctly.
I find that the internal wxWidgets timezone converter is a load of rubbish hence the manual setting. I always have it enabled (I'm in UTC).

When you adjusted the timezone manually did it correct the effective frame time?

I've been sitting here for the past 20 minutes trying to get 2.3.2b to consistently change the time zone, and it's not working in any predictable way. After changing the preference, sometimes it will adjust the download time, sometimes it won't, and I've even seen it add an additional 8 hours on occasion! The time will still come up UTC when I start 2.3.2b even when the manual time box is checked.

The effective PPD never changes even if the download time does.

This was never an issue in 2.3.1 -- I never had to set the time zone, and the download time & effective PPD have always been correct.

[uncle_fungus]

OK, well the download time as stored in the queue is in UTC, so it needs to be converted to your local time to show correctly.
I find that the internal wxWidgets timezone converter is a load of rubbish hence the manual setting. I always have it enabled (I'm in UTC).

When you adjusted the timezone manually did it correct the effective frame time?

I've been sitting here for the past 20 minutes trying to get 2.3.2b to consistently change the time zone, and it's not working in any predictable way. After changing the preference, sometimes it will adjust the download time, sometimes it won't, and I've even seen it add an additional 8 hours on occasion! The time will still come up UTC when I start 2.3.2b even when the manual time box is checked.

The effective PPD never changes even if the download time does.

This was never an issue in 2.3.1 -- I never had to set the time zone, and the download time & effective PPD have always been correct.

OK, I'll check this out and see what I find.
2.3.2b is built using a more up-to-date version of wxWidgets which might explain your new need to set the timezone. It doesn't explain why it doesn't save though.

Has anyone else in a non-UTC timezone noticed this behaviour?

[francois]

Has anyone else in a non-UTC timezone noticed this behaviour?

Yes, I am too.
At work, I also have the problem with the screen location when I start FahMon. (1152x864 screen resolution)
But not at home. (1440x900 screen resolution)

Thanks, uncle_fungus!

Best,
François

[uncle_fungus]

FahMon 2.3.2beta2 is up: http://fahmon.net/news/archives/2008/01 ... _29_56.txt

[ICE_9]

nm. I figured it out. I had it starting as a service in the background and it was still on.

Starting as a service? Does that work?

Sometimes. I will have to test it again to see if it's working correctly. BTW, is their a way to fix FAHmon from closing when I switch users then switch back, or when I remote in from remote desktop?