Game Development Community

TGE 1.5.2 Dedicated server responsiveness issue

by Tigeba · in Torque Game Engine · 09/08/2007 (9:48 pm) · 2 replies

Using the default SDK 1.5.2 and starter.fps, I can build either a dedicated binary, or run the normal binary in dedicated mode and I experience very poor responsiveness from the server. To be specific, it can take 4-5 minutes for DataBlocks to load on starter.fps. If you can get connected, any commands you send to the server lag badly.

I have verified this by connecting from various locations (I had some help from a few folks on the IRC channel). This appears to be an issue running the dedicated server on my LAN, as well as on a box I have in a colo. I can build and run a linux server with SDK 1.4.2 binary and clients seem to be able to connect as expected.

Another symptom is the responsiveness of the console. With the 1.5.2 build, when I hit enter there is around a 3-4 second lag before the prompt (%) comes up. With the 1.4.2 binary, the prompt comes back immediately. If I can actually get logged in, when I send a command to the server from the client, and have it echo on the console, the 1.5.2 version shows a similar 3-4 second lag.


The distos I am using are Fedora 5 and Centos 4.4., and I am running it with:

-dedicated -game starter.fps -mission starter.fps/data/missions/stronghold.mis

I would be willing to install another distro here at home if it would help for testing, but it would be impractical to change the distro I'm using on my colo box.

About the author

Recent Threads


#1
09/10/2007 (2:44 am)
I had the same issue on ubuntu 7.04, I "solved" this by setting to false the dsleep AUTO-optimisation (there is a -dsleep option to use to enable this, but with dedicated server a test is automatically launch and dsleep is set to true even if you have not wanted it to !)

in UNIXWindow386.cc

comment around line 738 or 744 : (...)->dSleepEnable(true)


and O my god : it's not lagging anymore, but there is no longer cpu optimisation cycles....
#2
09/19/2007 (1:17 pm)
I basically solved the problem by commenting the line as you suggested, and then altering the definition of Sleep() like follows

static inline void Sleep(int secs, int nanoSecs)
{
timespec sleeptime;
//sleeptime.tv_sec = secs;
//sleeptime.tv_nsec = nanoSecs;
sleeptime.tv_sec = 0;
sleeptime.tv_nsec = 1000;

nanosleep(&sleeptime, NULL);
}

Basically just defining a fixed sleep time, because whatever was getting passed in seems to be far far too big. My guess is that the problem stems from the windowed behavior where the game will sleep when the window loses focus. I'm sure there is a more elegant solution but I needed something quick and dirty, and that did it for me.