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

[toTOW]

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

This beta solved the issues with WebApp fields

[uncle_fungus]

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?

There might be but I haven't managed it so far. I think wxWidgets is interpreting the switch as a logoff event, which triggers FahMon to close. If I can work out how to separate logoff events from switch user events it should be possible.

This beta solved the issues with WebApp fields

Good.

[bollix47]

Compiled new beta on Ubuntu 7.10 and all went well. Noticed that on the display the second computer (Atlantis) is showing some of the times from the first computer. Also, the effective time on Challenger1 looks wrong to me but I'm no expert in these things.

FYI

Both running P2653.

-- Challenger1 --

Min. Time / Frame : 7mn 52s - 3221.69 ppd
Avg. Time / Frame : 7mn 59s - 3174.61 ppd
Cur. Time / Frame : 7mn 57s - 3187.92 ppd
R3F. Time / Frame : 7mn 57s - 3187.92 ppd
Eff. Time / Frame : 14mn 20s - 1768.19 ppd


-- Atlantis --

Min. Time / Frame : 11mn 43s - 2163.07 ppd
Avg. Time / Frame : 11mn 45s - 2156.94 ppd
Cur. Time / Frame : 7mn 57s - 3187.92 ppd
Cur. Time / Frame : 11mn 43s - 2163.07 ppd
R3F. Time / Frame : 7mn 57s - 3187.92 ppd
R3F. Time / Frame : 11mn 43s - 2163.07 ppd
Eff. Time / Frame : 14mn 20s - 1768.19 ppd
Eff. Time / Frame : 16mn 53s - 1501.13 ppd


The 7mn+ per frame would be nice on Atlantis(E6600) but it's not likely to happen any time soon.

EDIT: I checked the Eff times using the last version of FAHMON and both are much higher on the beta.

[uncle_fungus]

Compiled new beta on Ubuntu 7.10 and all went well. Noticed that on the display the second computer (Atlantis) is showing some of the times from the first computer. Also, the effective time on Challenger1 looks wrong to me but I'm no expert in these things.
The 7mn+ per frame would be nice on Atlantis(E6600) but it's not likely to happen any time soon.

EDIT: I checked the Eff times using the last version of FAHMON and both are much higher on the beta.

Ooh, that looks like some impressive incompetence on my part, sorry about that.

The effective times may be affected by a timezone offset bug that I'm looking into at the moment, see here: http://trac.fahmon.net/ticket/87

[bollix47]

Ooh, that looks like some impressive incompetence on my part, sorry about that.

The effective times may be affected by a timezone offset bug that I'm looking into at the moment, see here: http://trac.fahmon.net/ticket/87

I am not using UTC so it's probably the same problem.

If I find anything else I'll check the tickets first.

Thanks for the link.

[ICE_9]

My html output seems wierd.

http://home.orbitelcom.com/cweldridge/stats.html

Mainly because it says 1760 points points.

Do I need to report that as a bug, and how do I do that?

[uncle_fungus]

My html output seems wierd.

http://home.orbitelcom.com/cweldridge/stats.html

Mainly because it says 1760 points points.

Do I need to report that as a bug, and how do I do that?

No, thats fixed in beta2 http://fahmon.net/news/archives/2008/01 ... _29_56.txt

[Hyperlife]

Did 2.3.2b change the method for determining a WU's exact download time? There now seems to be a discrepancy in the reported download time when compared to unitinfo.txt on some WUs, but not all of them.

For example, under 2.3.1, a WU I have running has a reported download date of 4:40AM on January 27. The unitinfo.txt file for that WU matches the time exactly (when accounting for the time zone difference).

Under 2.3.2b2, the same WU has a reported download date of 4:21AM on 1/27.

I just went through all my clients and found the following discrepancies with unitinfo.txt:

Client #1 (WinXP 6.0b console, P2452): 21 minutes
Client #2 (WinXP 6.0b console, P2452): 19 minutes
Client #3 (Linux 6.0b SMP, P2653): None
Client #4 (WinXP 6.0b console, P2451): 19 minutes
Client #5 (WinXP 6.0b console, P3624): None
Client #6 (WinXP 6.0b console, P3615): None
Client #7 (Linux 6.0b single processor, P2453): 18 minutes
Client #8 (Linux 6.0b single processor, P1487): 1 minute

It's not off by much, but I thought I should bring it up. Let me know if you want a bug report filed for this.

This is a separate issue from the time zone offset problem, of course.

[uncle_fungus]

Did 2.3.2b change the method for determining a WU's exact download time? There now seems to be a discrepancy in the reported download time when compared to unitinfo.txt on some WUs, but not all of them.

It's not off by much, but I thought I should bring it up. Let me know if you want a bug report filed for this.

This is a separate issue from the time zone offset problem, of course.

Yes, version 2.3.2 uses the queue file to retrieve that information now. Unitinfo.txt is only used as a fallback for working out the % complete if it's impossible to get that from the logfile.

At the moment FahMon is using the "Issue" time in the queue which is the date that the server sent out the WU. I used this rather than the "begin time" as it gives a better idea of effective PPD because it takes into account the download time too.

You can check the exact values by downloading qd and running it on your queue file. Look for the line that starts with "Issued" for the current queue index and you should see the same discrepancy (in theory).

Code: Select all

[uncle_fungus@Iguana CPU1]$ ./qd | grep issue
  issue: Fri Nov  2 11:30:05 2007; begin: Fri Nov  2 11:30:10 2007
  issue: Sun Nov  4 04:00:57 2007; begin: Sun Nov  4 04:00:58 2007
  issue: Tue Nov  6 18:10:37 2007; begin: Tue Nov  6 18:10:45 2007
  issue: Thu Nov 15 08:19:31 2007; begin: Thu Nov 15 08:19:56 2007
  issue: Tue Nov 20 13:39:36 2007; begin: Tue Nov 20 13:40:23 2007
  issue: Wed Nov 28 16:57:57 2007; begin: Wed Nov 28 16:57:58 2007
  issue: Tue Dec  4 16:29:47 2007; begin: Tue Dec  4 16:29:27 2007
  issue: Sun Dec 23 08:13:02 2007; begin: Sun Dec 23 08:06:39 2007
  issue: Sat Dec 29 05:35:50 2007; begin: Sat Dec 29 05:35:51 2007
  issue: Tue Jan  8 20:26:02 2008; begin: Tue Jan  8 20:28:57 2008

As you can see by mine there are also discrepancies which can be due to download time, and also the server clock/local clock being inaccurate. (You'll notice the 7th and 8th items in my queue list started before they were issued )

[Hyperlife]

Yes, version 2.3.2 uses the queue file to retrieve that information now. Unitinfo.txt is only used as a fallback for working out the % complete if it's impossible to get that from the logfile.

Yup, that explains the difference. Thanks!

[uncle_fungus]

Can I assume from the lack of comments that the high CPU usage bug(s) and the location corruption bugs are no longer present in the betas?

If so, I've got one more beta to release (which if you're clever you can already download) then it can go public...once I've finished improving the documentation that is

[toTOW]

FAHmon beta2 crashed when I finished a p2619 (A2 core) ... (it was a gen 3 WU ... completition was at 400%)

I was unable to restart FAHmon unless it gets a new WU (it got a 2653).

[uncle_fungus]

FAHmon beta2 crashed when I finished a p2619 (A2 core) ... (it was a gen 3 WU ... completition was at 400%)

I was unable to restart FAHmon unless it gets a new WU (it got a 2653).

Hmm, thats not good. I added some code to try and cope with the % completion issues, which may be the cause, I don't know. The 2619's I've had recently have all been gen 0.

[dicecca112{LR}]

Can I assume from the lack of comments that the high CPU usage bug(s) and the location corruption bugs are no longer present in the betas?

If so, I've got one more beta to release (which if you're clever you can already download) then it can go public...once I've finished improving the documentation that is

I think I have b1 (it might be 2 though), and its working great. I can test b3 or whatever you haven't released to the public if you PM me how.

[uncle_fungus]

Can I assume from the lack of comments that the high CPU usage bug(s) and the location corruption bugs are no longer present in the betas?

If so, I've got one more beta to release (which if you're clever you can already download) then it can go public...once I've finished improving the documentation that is

I think I have b1 (it might be 2 though), and its working great. I can test b3 or whatever you haven't released to the public if you PM me how.

b1 is called FahMon 2.3.2beta, b2 is called FahMon 2.3.2beta2

I'll work out what causing the crash bug toTOW mentioned before putting out beta3