Well I guess you have a limited imanigation. The first place I would start
is your process where an admin clicks to start a new server or shut down a
server. I asume that you have an existing structure in place that manages
this now? so maybe I gave you to much credit, If you have a structure in
place then the ease of making it a smarter process is an addtion to your
exsiting function on that given server to check the load of all CPU's and
set affinity, even say not this server go to the next server in the list.
I didn't say anything about recoding the schedular for windows, I only
express that I have felt the pian in multi threaded applications that have
critical events dependent on proper timing, and in most cases your have to
have one threaded process monitor all threads to get anywhere close to
correct timing, but that again could lead to lag here, lag being the reality
that your waiting for something before you move on.....
Dustin Tuft
From: "Steven Hartland" <[EMAIL PROTECTED]>
Reply-To: hlds@list.valvesoftware.com
To: <hlds@list.valvesoftware.com>
Subject: Re: [hlds] CS1.6 Servers all bound to 1 CPU?
Date: Sun, 9 Apr 2006 22:39:07 +0100
If you know how to statically determine a dynamic process then please
let us all know as Im sure that would be a great breakthrough in computer
science.
Your basic solution of round robin would be unworkable as there are
too many dynamic variants. You may be running your two servers quite
happily but we are talking about many hundreds of servers across may
hundreds of varying spec machines running multiple varying games
that can change at any second triggered by an admins click.
Its no surprise that one of the most difficult tasks in an OS is the
scheduler
and as such I dont believe reinventing the wheel to satisfy the temporary
needs of one game is something we should be wasting resources on
do you?
Steve
----- Original Message -----
From: "Dustin Tuft"
Just as a suggestion, you might try re-evaluating your process. It seems
clear that the way your creating your servers does not allow flexable
programing to control affinity, since your way out side of what I am sure
Valve would consider standard deployment it might be faster for you to
build
a smarter dynamic process, possibly a program that trackes the diffrent
servers and sets affinity based on the current CPU load. Then you could
round robin the servers as they start up taking the CPU with the lowest
load, you might even think about leaving CPU0 out of the mix so the
windows
OS doesn't have any complication or get over loaded durning peak game
play.
I have been running a dual CPU box from the beging of DOD and I have
always
found that setting the affinity greatly increases the game server's
stablity
even before they patched the server to set affinity by it's self.
CPU's get bussy and when your busses are bussy with I/O a CPU can fall
behind and there is nothing to correct that not even a better built timer.
if you take in the whole system all the way to client Hard drives over the
network, chances are your server CPU spend more time waiting to process
data
then any thing else.
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the
person or entity to whom it is addressed. In the event of misdirection, the
recipient is prohibited from using, copying, printing or otherwise
disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone (023) 8024 3137
or return the E.mail to [EMAIL PROTECTED]
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
