Page 18 of 60

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

Posted: Thu Jun 05, 2008 10:30 pm
by wysiwyg_bill
The FAH client running on the same PC as FahMon started showing up as "_(0)" which links to anonymous. It *used* to work. I see the correct user and team in my folding console window but not with FAHMon.

The others folders I'm monitoring over the network are still fine. I've cleared out the FahMon config files and recreated the monitored clients but that made no difference. I also stopped the folding client and cleared out all of the log files but that didn''t help either. I also stopped the FAH client and renamed the config file and reconfigured with "fah -configonly" but that didn't make any difference either.

I'm running FahMon 2.3.2b and the Folding Console SMP client 5.92 on a PC with Windows XP Professional 32 bit.

Any ideas? Where does FAHMon get the user ID information it displays?

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

Posted: Thu Jun 05, 2008 10:34 pm
by uncle_fungus
The information is obtained from the queue.dat file, which is only written at the time a unit is assigned. This has a side effect of not reflecting any changes you make to your configuration until the next WU is downloaded.

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

Posted: Tue Jun 10, 2008 3:18 pm
by DriveEuro
Image

I'm having an issue with the PPD displaying properly.
I'm using the NotFred diskless folding through VMware. The PPDs sometimes show, but mostly show as *Hung*. This PPD is displaying weird. I rebooted the VM too and restarted Fahmon and its still displaying this.

As a side question... Why does Fahmon have a hard time calculating PPD from the NotFred diskless folding suite? Sometimes it will display it, but most of the time it shows as *Hung*. Any possible fix for this in the works?

Thanks

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

Posted: Tue Jun 10, 2008 3:51 pm
by uncle_fungus
Not sure why that PPD value is the way it is. Maybe the benchmarks database has got corrupted, since that's where it will be reading from at the moment (the WU hasn't completed enough frames yet).

The issue with VMs is that they can't keep time accurate with the host. Since FahMon relies on timekeeping to produce meaningful values there's not a lot that can be done. If you enable the asynchronous clocks option in FahMon that may help some, but all that will do is turn the clients blue. The PPD could still be completely wrong if the VM isn't running to time.

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

Posted: Tue Jun 10, 2008 3:59 pm
by DriveEuro
Ignore asynchronous clocks is enabled. Been for over a year.

VM clock times match host clock times too. Even after a few days of running the VM times still haven't wandered.

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

Posted: Wed Jun 11, 2008 7:47 am
by bruce
Doesn't anybody run "timed" any more?

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

Posted: Wed Jun 11, 2008 8:20 am
by theMASS
bruce wrote:Doesn't anybody run "timed" any more?
What does run "timed" mean :?:

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

Posted: Wed Jun 11, 2008 9:09 am
by bruce
The daemon "timed" synchronizes the clocks of networked *inux machines to one machine that's running a master clock. Microsoft had something like that for WIndows, but it doesn't seem to work any more, though you can download things like Atomic-Clock-Sync or other programs that can sync your clock with one of the government's master clocks.

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

Posted: Wed Jun 11, 2008 3:56 pm
by smoking2000
bruce wrote:The daemon "timed" synchronizes the clocks of networked *inux machines to one machine that's running a master clock. Microsoft had something like that for WIndows, but it doesn't seem to work any more, though you can download things like Atomic-Clock-Sync or other programs that can sync your clock with one of the government's master clocks.
timed is quite old, no one uses that anymore.

ntpd on the other hand is installed on any serious UNIX box (often by default even).

But unless you sync your hardware clock with NTP once a month or so, the drift of the clock will become too big anyway.
But this is only an issue on servers which are seldomly rebooted, as desktop which is rebooted weekly or more often will run ntpdate at boot so the drift is kept small.

The NTP protocol and your ISPs NTP server or the excellent pool.ntp.org NTP servers are the way to go, to keep you computer clocks in sync with the rest of the world now that we buried timed. Windows ships the w32time utilty to sync your clock with an NTP server, and Unix machines can install ntpdate or use the ntp client of the ntp server package.

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

Posted: Wed Jun 11, 2008 4:08 pm
by gwildperson
Is there a way to have NTP update more frequently? Linux in a Virtual Machine requires the AMD patch to keep reasonable time, but it still may be drifting more than the real hardware drifts.

Is there a NTP for Windows so that both can be synchronized to the same clock?

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

Posted: Wed Jun 11, 2008 4:41 pm
by smoking2000
gwildperson wrote:Is there a way to have NTP update more frequently? Linux in a Virtual Machine requires the AMD patch to keep reasonable time, but it still may be drifting more than the real hardware drifts.

Is there a NTP for Windows so that both can be synchronized to the same clock?
As I posted before, the w32time utility is the default NTP client on Windows.
You can use this and the publicly available NTP servers of pool.ntp.org (if your ISP doesn't have NTP servers) to sync your clocks.

On UNIX systems you have ntpd, the NTP daemon, and a client ntpdate to set the clock.
You can schedule ntpdate to sync your hardware clock on a weekly basis using cron and a simple wrapper shell script.

Schedule cron to run the script every first day of the week at 3:00 (timezone changes like daylight savings go in effect at 02:00 or 03:00):

Code: Select all

# Sync system time with NTP
0 3 * * 0 /usr/local/bin/sync-time.sh
/usr/local/bin/sync-time.sh:

Code: Select all

#!/bin/bash

# Get the NTP server IP from the NTP server configuration /etc/ntp.conf
SERVER=$(grep ^server /etc/ntp.conf | awk '{print $2}' | head -1)

echo -n "Stopping ntpd ... "
/etc/init.d/ntpd stop > /dev/null 2>&1
echo    "done"

echo -n "Syncing system time with NTP ... "
/usr/sbin/ntpdate $SERVER > /dev/null 2>&1
echo    "done"

echo -n "Setting hardware clock to system time ... "
/sbin/hwclock --systohc > /dev/null 2>&1
echo    "done"

echo -n "Starting ntpd ... "
/etc/init.d/ntpd start > /dev/null 2>&1
echo    "done"
This does assume that your running the ntpd service too, if not, you can leave out the calls to /etc/init.d/ntpd and only sync the system time (OS time) with NTP and hardware clock (BIOS time) with that of the system.

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

Posted: Sun Jun 15, 2008 2:49 am
by Beremat
Thanks for this great app, works flawlessly using even the old, deprecated Windows Folder Sharing! :D

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

Posted: Wed Jun 18, 2008 5:02 pm
by benadderson
I've been directed here to post a query: I'm informed that, when calculating PPD, it is better to use the "effective rate" setting than the "all frames" setting. Can anybody tell me why that is?

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

Posted: Wed Jun 18, 2008 5:07 pm
by uncle_fungus
Sure, the "all frames" method bases it's calculation on a set of 255 stored frames. As soon as 255 frames have been stored new frame times no longer count, which means if the spec of your machine suddenly changes, or the core suddenly becomes more efficient the data will be obsolete.
The "effective rate" method calculates the frame time based on (time now - download time) / current frame which gives a much better estimate of your PPD and frame time across the current WU.
The other methods, "last frame only" and "last 3 frames" show your instantaneous PPD, and a smoothed instantaneous PPD. This may not always accurately reflect the overall PPD you get for a particular WU.

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

Posted: Wed Jun 18, 2008 6:10 pm
by slegrand
uncle_fungus wrote:Sure, the "all frames" method bases it's calculation on a set of 255 stored frames. As soon as 255 frames have been stored new frame times no longer count, which means if the spec of your machine suddenly changes, or the core suddenly becomes more efficient the data will be obsolete.
The "effective rate" method calculates the frame time based on (time now - download time) / current frame which gives a much better estimate of your PPD and frame time across the current WU.
The other methods, "last frame only" and "last 3 frames" show your instantaneous PPD, and a smoothed instantaneous PPD. This may not always accurately reflect the overall PPD you get for a particular WU.

Ok that's weird... How does effective frame time therefore end up faster than all frames?

And is there a way to refresh the all frames?