Folding Forum

I had this running on two machines with the .iso and fold64.vbx in the VMPlayer folder. On one machine all was well and on the second all was running fine except that for some reason it seemed to be reading the system clock about 3.5x faster than reality. For instance, it entered a 15-minute checkpoint about every 4 minutes. At first I just thought it was FahMon orienting itself until some time went by and it was still happening, yet the other machine was reporting correctly.

At just under a day of this and on Frame 71 of a 2653 it reported itself as being past the deadline (due to the steroids clock) and deleted the WU and tried to get another. Needless to say, I've killed the process on that machine and gone back to Win 5.91 until I can get this fixed.

Does anyone know why in the world it's doing this and how to fix it? I would really like to run this because it's more efficient and I can do WU's faster, but obviously doing them this way is doing no good at all.

I'll bet you have an AMD cpu. There a CPU driver that fixes the crazy clock.

Bruce, you're absolutely right. Surprisingly, there's nothing on the AMD site other than the standard clock utilities, nothing in the forums that is showing up in a search. Is there anyone that's familiar with this that can point me? I would have thought a driver would probably be on the AMD site. Funny it's affecting the X2 4200+ and not the X2 4000+, but I'm just glad someone's at least heard of this, was beginning to think it was me that's crazy as opposed to the clock.

Check the motherboard site for the cpu driver.

There are no drivers on the motherboard site (pcchips) for cpu's, confirmed by a DriverAgent scan as well.

I've gotten new cpu drivers when updating the bios for several Gigabyte mobos. Have you just googled it?

Also see here: http://kb.vmware.com/selfservice/micros ... nalId=1420

I don't know if it's the VMWare/nf combo as nf is built on the 2.6.22 kernel which shouldn't have the issue as the issue was corrected in the 2.6.18 kernel.

nf also disables ntpd when it detects a VM environment.

I would check AMD's Powernow and CoolnQuiet type features and disable them if they are enabled.

Thanks for the suggestions, folks. I've done a lot of reading, I have the AMD-specific "features" disabled, and I flashed my bios. Still no joy. Given the 8% increase I'm enjoying on the very similar, just slightly lesser machine with it all working, I'm still bound and determined. I'm going to try MS Virtual PC this weekend to see what happens. I'd live with the clock thing no problem, except that it kills the WU, thinking the deadline had passed.

ArVee wrote:I'd live with the clock thing no problem, except that it kills the WU, thinking the deadline had passed.

I think you'll be able to find a fix for the clock, but in the meantime you can reconfigure the client. There's an advanced option to ignore the local clock. WUs will continue to be processed even if the local time/date says they've expired. (You won't get credit for them after they really expire, though, since the server checks for expiration too, with it's clock and it knows exactly how long you've had that WU.)

Oh!! That would do! Why haven't I seen that before? So just run fah -configonly?

ArVee wrote:Oh!! That would do! Why haven't I seen that before? So just run fah -configonly?

Correct. Answer Yes to Ignore deadline information. (mainly useful if the computer's system clock frequently has errors)? in the Advanced options section, as bruce said.

Thank you.

ArVee wrote:Thanks for the suggestions, folks. I've done a lot of reading, I have the AMD-specific "features" disabled, and I flashed my bios. Still no joy. Given the 8% increase I'm enjoying on the very similar, just slightly lesser machine with it all working, I'm still bound and determined. I'm going to try MS Virtual PC this weekend to see what happens. I'd live with the clock thing no problem, except that it kills the WU, thinking the deadline had passed.

Does your BIOS have HPET? (usually in the power section) If it does check to see if it's active and using 64-bit mode. If it is active try disabling it.

You can try using VMWare Server instead of Player.

bruce wrote:There's an advanced option to ignore the local clock. WUs will continue to be processed even if the local time/date says they've expired. (You won't get credit for them after they really expire, though, since the server checks for expiration too, with it's clock and it knows exactly how long you've had that WU.)

Unfortunately at this time that option isn't configurable when using notfred's software.

I had already installed and tried Server when I hit the problem in Player. Made no difference.

BUT if nothing else I'm learning a bunch, lol. HPET was news to me, and sure enough, it was Disabled in BIOS. I've now enabled it, 64-bit. I will now let this wait until the current Windows WU finishes, scheduled for tomorrow midday and when I have time to deal with any snags, and try VMServer again to see if the HPET activation has cured the runaway clock (which btw is of course fine under Windows).

Will post either way as to the outcome.