I'm not sure exactly how to figure this out, who to ask, or where to begin looking for this kind of problem. But here goes.

I recently upgraded both of my servers to dual core AMD64 CPUs. Obviously I am thrilled with the new speed and such. But it seems to have had an interesting side affect I wasn't counting on.

In the game_loop handlers that deal with idling descriptors, my code is just like any other Merc derivative. It adds one to the idle counter with each pulse as it runs the game loop. Immortals are all set to idle off the mud after 2 hours. Lately though, this has been drastically cut to somewhere in the neighborhood of 15 minutes.

The deeper implications of this should be clear. This would suggest that all of the handlers that game_loop stalls time for are firing off at greatly increased intervals. Zeno was able to verify this easily enough on his game which is also affected by this ( same server etc ). It appears as though everything has been accelerated to about 8x normal speed.

Is this something that is known and can be corrected? Or have I stumbled into one of those uncharted areas us bleeding edgers often end up in?

EDIT: After a make clean and reboot, the skew is down to twice normal speed.

Sounds to me like, instead of using the system clock to determine when X time has passed, the coders of your driver got lazy and used execution loops. You would get the same screwball effect on games made for 386 processors, when run on pentiums, because the games didn't time their events by any accurate clock, they just added loops into the code, then adjusted those until they where the right "time".

How to fix it? Find the code that is being used to produce the heartbeat event and increase the loop delay (but be warned that you lose all benefit gained by the faster system doing this, since you can't make "shorter" event cycles that way), or... recode the damn thing to use the system clock to figure out when to generate a heartbeat, so its based on something rational, not the fiddly BS they appear to be using.

Mind you, its only a guess that this is the problem, having never looked at the code for the driver, but it seems very probable.

The application could be receiving signals that is cutting select() short. Or perhaps more likely, the calculation of the stall time is messed up on 64 bit processors, possibly down to sizeof(long) being twice as big as it typically was on the typical target machine for the average Diku.

Actually it turns out it's probably something hardware/OS related. There was lengthy discussion of the topic of select() here:

And I posted for some help with the issue of x86_64 Fedora here: which led me to some kernel tweakage to try and fix it. Not sure yet if it was effective.