• 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.

VMWare Diskless time problem

O

ojmalik

n00b
Joined
Jan 18, 2004
Messages
49
Did a quick search and couldnt find any answers anywhere.

I'm having a problem where the times in fahlog are incorrect. Both fahspy and fahmon get confused by this and can't calculate ppd correctly. here's a snip from one of the log files:

[18:29:51] Timered checkpoint triggered.
[18:29:51] Writing local files
[18:29:51] Completed 240000 out of 500000 steps (48 percent)
[18:29:51] Timered checkpoint triggered.
[18:29:51] Writing local files
[18:29:51] Completed 245000 out of 500000 steps (49 percent)
[18:29:51] Timered checkpoint triggered.
[18:29:51] Writing local files
[18:29:51] Completed 250000 out of 500000 steps (50 percent)
[18:29:51] Timered checkpoint triggered.
[18:29:51] Writing local files
[18:29:51] Completed 255000 out of 500000 steps (51 percent)
[19:44:48] Timered checkpoint triggered.
[19:44:48] Writing local files
[19:44:48] Completed 260000 out of 500000 steps (52 percent)
[19:44:48] Timered checkpoint triggered.
[19:44:48] Writing local files
[19:44:48] Completed 265000 out of 500000 steps (53 percent)
[19:44:48] Timered checkpoint triggered.
[19:44:48] Writing local files
[19:44:48] Completed 270000 out of 500000 steps (54 percent)
[19:44:48] Timered checkpoint triggered.
[19:44:48] Writing local files
[19:44:48] Completed 275000 out of 500000 steps (55 percent)
[20:58:37] Timered checkpoint triggered.
[20:58:37] Writing local files
[20:58:37] Completed 280000 out of 500000 steps (56 percent)
[20:58:37] Timered checkpoint triggered.
[20:58:37] Writing local files
[20:58:37] Completed 285000 out of 500000 steps (57 percent)
[20:58:37] Timered checkpoint triggered.
[20:58:37] Writing local files
[20:58:37] Completed 290000 out of 500000 steps (58 percent)
[20:58:37] Timered checkpoint triggered.
[20:58:37] Writing local files
[20:58:37] Completed 295000 out of 500000 steps (59 percent)

For some reason the time in the VM isnt progressing as it should. Has anyone seen this before?
I have the machines set to idle priority when uncaptured, but it does it even if i have them at normal priority. I am using VMWare workstation with notfred's folding cd, no backup. I'm thinking about letting them finish, then trying vmware server instead, but just wanted to see if anyone else had run into this in the meantime.
this is a q6600 @ 3.2ghz, 2 gigs memory, xpsp3

Thanks for any insight. I'm trying to bring up as many machines as i can for [H]ardApe

got another q6600 and e8400 left to bring up after this.
 
Do you have VMWare tools installed ?
If not then extract and install them, as I've found they fixed the time stamp for me.

Other than that just set the client to ignore deadlines.
That way if the clock jumps a lot forward at any point, you dont loose any work.

Luck ............ :D
 
I've had that happen, because of the load on the system and the VM, it doesn't keep the time synced properly. It will show the wrong time... I just let it go myself.. I never missed any deadlines or anything...
I never found a way to fix the issue tho...

as far as VMware tools go... I don't think you can install them with the diskless client.. atleast I never could.
 
VMWare server will not fix the problem for you. I have the same problem on one of my systems. I'm not 100% sure what causes it but in my case I think it was because I moved the VM images from another system. When on the previous system the time was usually right on. Now, the time in the VMs runs rather fast. I made a change or two to one of the VMWare files and managed to slow the clock down some, but it still runs fast.

There is no fix from VMWare for this issue. There's a workaround or two like what I did but they aren't perfect. I'm at work right now and can't do a search for the adjustment but it has to do with something in the one of the VM image files in regards to the clockspeed of the processor. The way VMWare keeps time is based on the clockspeed of the processor.

If I have a chance tonight, I'll see about digging up the info for making the adjustment to possibly get the time close. It's still a good idea to make the change to the client to ignore deadlines.

 
You must log in or register to reply here.
Back
Top