Interesting MP Server Hosting Bug/Issue

PvK · #1 February 23rd, 2007, 09:32 PM

Yes. I don't know of anyone but you having tested it on a virtual machine.

lch · #2 February 23rd, 2007, 09:48 PM

Seems to be an issue with VMware, not the server per se. Have you tried googling for "vmware timekeeping"? The first two hits are some technical whitepaper which I didn't bother to open (bah, PDF), the third and fourth (one for Windows, one for Linux) titled "Host Power Management Causes Problems with Guest Timekeeping" has some info and links and something that seems to be a possible workaround.

Velusion · #3 February 23rd, 2007, 09:57 PM

Oh yea... I spent hours going through the white papers, etc. Most of the timekeeping issues involve the clock going slower... only a few talk about it going faster, and I tried those fixes. After lots of research I came upon the AMD dual-core windows patch - and that fixed it with the OS.

I don't know what Dom3 is looking at when it keeps time, so I'm not sure whose fault it is really. Probably VMwares or AMD... unless Dom3 keeps track of time in some non-standard way. It certianly doesn't sync up with the OS (which makes sense).

lch · #4 February 24th, 2007, 08:48 AM

Just checking, so you have tried to finetune your settings manually like described in point 3 in that web page?

Quote:

Edit config.ini, adding the lines described below.

The example presented here assumes that the host computer has a maximum speed of 1700MHz. The first line is the most important one. It should be your host computer's maximum speed in KHz�that is, its speed in MHz times 1000, or its speed in GHz times 1000000.

host.cpukHz = "1700000"

host.noTSC = "TRUE"

ptsc.noTSC = "TRUE"

The second and third lines enable a mechanism that tries to keep the guest clock accurate even when the time stamp counter (TSC) is slow.

Velusion · #5 February 24th, 2007, 02:15 PM

Quote:

lch said:
Just checking, so you have tried to finetune your settings manually like described in point 3 in that web page?

Quote:

Edit config.ini, adding the lines described below.

The example presented here assumes that the host computer has a maximum speed of 1700MHz. The first line is the most important one. It should be your host computer's maximum speed in KHz�that is, its speed in MHz times 1000, or its speed in GHz times 1000000.

host.cpukHz = "1700000"

host.noTSC = "TRUE"

ptsc.noTSC = "TRUE"

The second and third lines enable a mechanism that tries to keep the guest clock accurate even when the time stamp counter (TSC) is slow.

Yep, using those switches now. I'm probably going to remove them now that the AMD patch seemed to fix the OS just to see if it makes a difference.

alexti · #6 February 25th, 2007, 12:51 AM

Velusion, I'm not sure how relevant it is, but there's a problem in VMWare that borks the timer functions on Linux on 64-bit AMD (dual core). The patch you have mentioned doesn't solve this problem. As of couple of months ago, there wasn't any solution to that.

Gandalf Parker · #7 February 23rd, 2007, 09:54 PM

Hmmm my install only shows these executables.
dom3_amd64
dom3_ppc
dom3_x86
and the Windows install creates a dom3.exe

On my server (Debian Linux on an x86) the install properly recognized the system and then linked the actual dom3 command to the dom3_x86 executable. If you are AMD but not 64 then Im not sure what it would choose.