Game Development Community

Client / Dedicated Server TGE 1.4

by CdnGater · in Torque Game Engine · 11/29/2005 (5:55 am) · 44 replies

I was wondering if anyone else has tried the Dedicated Server and Client setup for TGE 1.4? Its easy to setup. (And yes, its simply out of the box except for the minor creator change I posted someplace else)

One thing I am encountering, is that the client is very choppie when you move around, even Kork seems to be stuttering when he walks.

In the combined client/server its nothing is wrong. So has anybody else seen this in 1.4? do you know whats wrong and can share? (again yes, I have searched the forums)

Just one last thought, did GarageGames QA the Client / Dedicated Server setup that they so advertise?
Page «Previous 1 2 3 Last »
#1
11/29/2005 (3:26 pm)
You seem frustrated, Simon. :)

We've done several test sessions, and the networking has always worked great. Can you detail what sort of link you're running over, what sort of packet loss is going on, if you're using a stock mission or not, what object types and how many are in the scene, and what the NetGraph is showing?
#2
11/30/2005 (4:14 pm)
Yes Ben, I am.

I used the stock TGE 1.4 that was released by GG. You could not even run a dedicated server without a crash. So I guess you missed running dedicated servers in your testing.

Anyway, on a positive note, I found the problem. Its a change that GG did. Look at this thread to see what I am talking about www.garagegames.com/mg/forums/result.thread.php?qt=37170
#3
11/30/2005 (4:42 pm)
If the you cannot even start a dedicated server, then how could someone have done several test sessions with it? :p
#4
02/20/2006 (4:50 pm)
I believe Simon is saying that you can't run dedicated servers out of the box without crashing, which is true.

I've finally got the dedicated server to run with TLK 1.4, but the jitters are awful. I've tried the changes mentioned in the thread Simon found but they don't seem to help. My sense is that it gets worse the faster the server machines is.

It looks much better if I run the server on a PIII-800, but on my PIV-3Ghz or PIV-3.6Ghz, it is truely awful...
#5
02/22/2006 (10:48 am)
I've traced my problem back to my old friend the PerfCounter. If I don't use the PerformaceCounter in winWindow.cc, I don't see any stuttering at all! Can anyone else support this or is it just my four machines?

I'm going to try some tests on an AMD machine later to see if hyperthreading might still be the cause.
#6
02/22/2006 (5:12 pm)
The results are in. The people have spoken:

Turns out hyperthreading is probably not the issue. If I have mUsingPerfCounter set to TRUE on my dedicated server, I experience the massive jerkiness described above when running on either an Intel or AMD processor rated 3GHz or above.

If mUsingPerfCounter is forced to be FALSE, the server works like a dream.

The clients appear to be unaffected with either setting.

Now all that remains is for some industrious person to determine what performance counters are doing to the server...
#7
02/22/2006 (6:39 pm)
Quote:
I've finally got the dedicated server to run with TLK 1.4, but the jitters are awful

Quote:
The clients appear to be unaffected with either setting.

Was confused when I first read the question, and now I'm just as confused: Are you saying that your dedicated server is jittering when it's rendering?

Because dedicated servers don't render--they don't even launch a client. What exactly is jittering?
#8
02/22/2006 (7:51 pm)
Obviously the clients are jittery (that is the theme of this thread). :P

The jitters, I should describe, seem more like anti-lag. Rather than slowing the responsiveness of the client, it is more like constantly warping the client back to a previous location. One-step forward, one-step back. :\

In my tests, when connected to a dedicated server that is using the performance counter, my clients appearance is so jumpy, it is impossible to control. When the same machine is running a dedicated server with that flag turned off, it works like a charm.

The clients's performance counter setting does not appear to matter. Normally, the server and client Exes would be identical, but I obviously created an alternate that disabled the performance counter. Here's a matrix:

Server PC On, Client PC On - BAD
Server PC On, Client PC Off - BAD
Server PC Off, Client PC On - GOOD
Server PC Off, Client PC Off - GOOD

When the dedicated server ran on a much slower machine, the clients ran better. I assume that either the processor is a factor or perhaps my only slow machine isn't capable of using the performance counter. I should check that next.

I should also mention that I first noticed a problem when I was hosting a server with one client and then added two more clients. Only one, my AMD machine, appeared to be experiencing lag, although the net stats report nothing out of the ordinary. I then decided to try a dedicated server without a client in the off-chance I was somehow overloading my dev machine.

I hope that's a slightly clearer picture?
#9
02/22/2006 (7:54 pm)
Yah, I guess I misread the posts, sorry! There have been a couple of discovered bugs in 1.4 that may be related...I'll make sure the testing team is aware of your observations.
#10
03/01/2006 (1:14 pm)
What's the actual fix to run a Dedicated Server without having it crash using TGE 1.4? I couldn't find that info anywhere else in the forums.

Thanks
#11
03/01/2006 (1:54 pm)
Just need to disable initializing the Creator mod for dedicated servers.
#12
03/01/2006 (2:29 pm)
This seems like a massive game breaking bug. As Ive stated in my other post Im having the exact same issue. This should get fixed ASAP
#13
03/01/2006 (4:24 pm)
I'm not quite sure what the problem is, but dedicated server worked fine for the starter.fps, and it still did when i renamed it and edited it to my likings.. Buutttt... Why are some file locations hard-coded into the source/exe!? like the lightning things?
#14
03/08/2006 (2:12 pm)
This is what I changed:

mUsingPerfCounter = QueryPerformanceFrequency((LARGE_INTEGER *) &mFrequency);

to

mUsingPerfCounter = false;

It seemed to fix the jitters. What are the side effects of doing this? Im assuimg that line was in there for a reason.
#15
03/08/2006 (4:19 pm)
I'm getting these numbers from an old DirectX book, so they're probably accurate. The normal Windows timer has a resolution of 54ms under Win9x and 10ms under WinNT/2K/XP. 10ms if I can still do basic math is roughly 100 ticks per second, not counting the round-off time and all the time being spent by other Windows apps.

A high-resolution timer, if I understand it properly, uses a native processor counter to determing the elapsed time. Think of it as instructions per second where the number of instructions is assumed to be constant. By noting how many instructions have passed since the last call, you should be able to tell how much time has passed to something like a billionth of a second or better. The Frequency queried is the constant value used for the calculations.

Window's documentation makes it sound like the thing that gets counted is processor dependant. But the heart of the problem, I believe, is the assumption that the counter constant is in fact constant. I think hyper-threading or perhaps Windows threading is making this number unreliable. I know the timer gets more unreliable relative to the speed of the machine. It doesn't matter if it is Intel or AMD. It may be that it is related to my reliance on Visual Studio 6.0. It is probably related to all the neat caching and pipeline tricks they do these days.

Anyway, to answer your question about side effects, I can't imagine needing to run the server faster than the 10ms timer. Your client may have issues interpolating animation as it reaches 100fps, but should be fine in most cases.

Here's another related thread: Topic: Bug: QueryPerformanceTimer drifting. The proposed changes didn't help me back in 1.3, and they appear to be in 1.4 now.

Good luck!

Edit: Status of the 1.4 code.
#16
03/08/2006 (4:33 pm)
So if I understand you correctly, this would effect performace of your app if its running over 100fps. If thats the case then its no problem since anything over 60fps is just gravy. This fix or something similar should go into the HEAD because the problem is going to get worse as time goes by and processors get faster.
#17
03/08/2006 (5:36 pm)
I admit that I haven't dredged the code to see where and how time is used in all places, but I would think it would be safe except under high framerates.

As far as I remember, the client/server packets rates are only supposed to be around 10-30 / second, so I'm curious as to just what's really going on here and why it appears to be so different from 1.3.
#18
03/08/2006 (6:09 pm)
Just found a little newer information on MSDN from Feb 2006: Game Timing and Multicore Processors. Enjoy.
#19
03/09/2006 (3:08 pm)
Great research guys.
#20
03/10/2006 (2:13 pm)
Here's a MS support article that might also explain some of the problems: Computers that are running Windows XP Service Pack 2 and that are equipped with multiple processors that support processor power management features may experience decreased performance. I found this browsing through the Dungeons & Dragons Online tech forums.
Page «Previous 1 2 3 Last »