game_loop(), select(), and dual core CPUs

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding
View previous topic :: View next topic  
Author Message
Samson



Joined: 13 May 2005
Posts: 4
Location: United Socialist States of America

PostPosted: Sun Feb 11, 2007 6:24 am    Post subject: game_loop(), select(), and dual core CPUs Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Shadus



Joined: 01 Sep 2007
Posts: 8

PostPosted: Sun Sep 02, 2007 10:19 am    Post subject: Code Implementation Reply with quote

I don't know, but it seems like someone is depending on a loop as a counter instead of actual time, or using a bad algorithm. Just a bad code implementation that would take some tooling around with the actual code to fix and smash out.
Having that said, it should be firing on just one CPU, not both at all unless you're running it in a separate thread with an affinity for a different CPU. So your CPU core is the only thing factoring in on this.
But yeah, check for a loop that counts down for its timing or some such. A well implemented timing loop should keep very correct and scale with real time accurately.
Good thing my mud is tickless (ok, this was a shameless plug, but it can stand to be said!)

As for a fix? I don't know any codebases except my own. So I have no idea.
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
Samson



Joined: 13 May 2005
Posts: 4
Location: United Socialist States of America

PostPosted: Sun Sep 02, 2007 3:12 pm    Post subject: Reply with quote

Heh. I had forgotten I posted this here too until the email came in Smile

I ended up resolving this problem through the kernel flags at boot up. It has something to do with the hardware timers themselves, so the system clock was literally racing. I'd link to the post I made about this on fedoraforums.org but I've lost the link to it.

Since most Merc derivatives use a select() call which stalls for a certain period of time based on the system clock, it was totally thrown out of whack.

And further, removing all of the 32bit packages from the system solved a number of remaining problems that cropped up even after the system timer issues were fixed.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign