Hi

the clock-sync option in vmware-tools tells the virtual-machine only the daytime, date .... You can edit this in BIOS.

CPU-timings is another story.

Please try to change your HostOSType settings to Windows2000 or FreeBSD and check if this changes anything.

Before you make any experiments with this take a snapshot or set diskmode to nonpersistent.

Do you have any lines in your log that do repeat very often?

I think your problem is beyond my skills - if you want that someone with more technical background gets interested in this you have to supply all necessary information in your question at once. These guys don't like having to ask before answering anything.

Ulli Hankeln

the "maximum" CPU speed reported by

MSINFO32 is 598MHz - it should be 1700MHz.

That's the problem: your CPU is sometimes running faster than VMware Workstation expects it to be running.  See Knowledge Base article 709 for one workaround.

http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=709

There is also a workaround that doesn't require you to lock the CPU speed to a constant value: put the correct maximum CPU speed in your global config file.  On Linux hosts this file is /etc/vmware/config.  On Windows hosts,  it is normally C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\config.ini.  In both cases, the file may not exist; if so, create it.  Be sure to create it as a plain text file.  On Windows, you can use Notepad, but be careful when saving the file that Notepad does not add an extra .txt extension to the filename.

If your machine is 1700 MHz maximum speed, the lines to add to this file are as follows.  The first line is the most important one.

host.cpukHz = 1700000

hostinfo.noTSC = TRUE

tools.syncTime = TRUE

Those settings aren't documented, but we will be adding them into a knowledge base article soon.

hostinfo.noTSC basically tells the VM that you have SpeedStep, so the TSC won't be running at a constant speed and we should avoid using it as much as possible.  Unfortunately we can't completely avoid using it, which is why we still need a good estimate of the speed.

I put tools.syncTime there in an attempt to turn on tools time sync for you, but maybe that doesn't work properly in the global config file.  I'll check on that.

Thanks for reporting back on your results!

My thinking goes like this: by telling VMware the max

CPU speed, you ensure that the guest clock runs no

faster than the host clock.

That's right.

However, it could get behind when the CPU slows down.

So syncTime is turned on to sync it back up. Right?

That's partly right.  There is actually another mechanism that gets turned on by host.noTSC=true (or which can also turn itself on automatically) that tries to keep the guest clock accurate even when the TSC is slow.  But it's still good to turn on tools.syncTime as a further backstop.