• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Not complaining... but it doesn't seem right..

G

Greatone123

[H]ard|Gawd
Joined
May 10, 2006
Messages
1,293
ok first off I bow down to the might of the [H]orde I do not fold for Team 33, for my own reasons, but I come seeking knowledge...


I've got 3 computers running SMP. (I use Notfred's SMP Folding CD)

1: 3800+ Skt 939, 3GB ram ALL STOCK (headless SMP) FAHMON: 887 PPD

2: 3600+ Skt AM2, 1GB ram OCed @ 2.2 Ghz (Headless SMP) FAHMON: 1024 PPD

3: 4800+ Skt Am2, 2GB ram OCed @ 2.8 Ghz (VMWare SMP) FAHMON: 2500 PPD <--

#3 is running Windows 2003 EE SP2

Seriously do you see what I'm talkin about now? NO WAY can 600 Mhz more then 2x my PPD.... it's the same project 2605 I don't know if it's a fluke or what... it's done this for 2 WUs

[22:28:59] Folding@Home Gromacs SMP Core
[22:28:59] Version 1.74 (November 27, 2006)
[22:28:59]
[22:28:59] Preparing to commence simulation
[22:28:59] - Ensuring status. Please wait.
[22:29:16] - Assembly optimizations manually forced on.
[22:29:16] - Not checking prior termination.
[22:29:17] - Expanded 2438763 -> 12897049 (decompressed 528.8 percent)
[22:29:17] - Starting from initial work packet
[22:29:17]
[22:29:17] Project: 2605 (Run 15, Clone 231, Gen 17)
[22:29:17]
[22:29:17] Assembly optimizations on if available.
[22:29:17] Entering M.D.
[22:29:23] Rejecting checkpoint
[22:29:23] Protein: Protein in POPCExtra SSE boost OK.
[22:29:23]
[22:29:23] Extra SSE boost OK.
[22:29:24] Writing local files
[22:29:24] Completed 0 out of 500000 steps (0 percent)
[22:39:42] Writing local files
[22:39:42] Completed 5000 out of 500000 steps (1 percent)
[22:50:02] Writing local files
[22:50:02] Completed 10000 out of 500000 steps (2 percent)
[23:00:19] Writing local files
[23:00:19] Completed 15000 out of 500000 steps (3 percent)
[23:10:49] Writing local files
[23:10:49] Completed 20000 out of 500000 steps (4 percent)


I'm by all means not complaining... just wondering if someone could possibly explain why? according to this It will complete 1 SMP unit in less then 17 Hrs... do I need to buy more 4800+'s lol?

http://24.28.80.122/screen.jpg



If this is normal... then what's wrong with my others?! lol and if it's not... any ideas why it's so awesome? any info needed feel free to ask cause I'm just dieing to figure it out...
 
That's not normal indeed and it's possible you got some of the really short ones... It may also be a fluke and will produce incorrect results.

There is no way a AMD can get this result compared to Core 2 processors.

 
The time in the VM's tend not to be correct if your doing anything on/with the box.
You need to time it by hand and find out exactly how fast/slow the clock in the VM is running.

On my pure folding boxen which run the VM, the clock is a few mins per hour fast.
Which is why FahMon does not like them, always says they are hung.
On my work box the clock runs around 5-30 mins per hour slow.
Which is why one VM shows at 1,711 PpD and the other shows at 2,539 PpD with FahSpy.
Both are actualy folding around 1,500 PpD each.

Luck .............. :D
 
would the times effect the FAHlog tho? if it was slow/fast the time between frames would be the same still wouldn't it?


hah I looked at another fahlog on the other machine... they both started at the same time... 1 sais 19:##:##... the VMWare one says 22:##:##... so it's very off... ... still would it effect the FAHlog? since that's stored on the VM time might be wrong but it's consistantly wrong...
 
Greatone123 said:
would the times effect the FAHlog tho? if it was slow/fast the time between frames would be the same still wouldn't it?


hah I looked at another fahlog on the other machine... they both started at the same time... 1 sais 19:##:##... the VMWare one says 22:##:##... so it's very off... ... still would it effect the FAHlog? since that's stored on the VM time might be wrong but it's consistantly wrong...
Click to expand...

If the clock is running slow then say the boxen will still fold at ~20 Mins per Frame.
Its just that the FAHlog file shows them running at only ~15 Mins per Frame.
All the monitoring programs work off the times shown in the log file, hence the inflated PpD.
If you know the time when you started it, you can look at the time now and the time shown in the log file. Does the time difference match or is the log file showing a shorter period of time.
If its shorter then..........
time run in logfile/ time run x PpD shown = correct PpD.
Easy....... :p

Edit.
Your screen shot shows the Windoze time at ~10:00 am but the VM time at ~16:00. something is not synced.
If the time is running wrong then you need to config the clients to ignore the deadlines.
If it is running slow and then catches up when it restarts then it could cause the client to think its passed the dead line and dump a part done work unit, when in fact you still hasve plenty of time to finish it.
Luck ................ :D
 
I'll have to dig around but theres a fix for the incorrect time in vmware. It doesnt fix it 100% but it does keep the time pretty close to accurate. I encountered the same phenomenon when i first tried vmware. I was blown away by the folding potential of my opty165....until reality took hold :p
 
You must log in or register to reply here.
Back
Top