I do this already in my management system.  I used to use XCPU.exe, but
about a year ago I switched to using my own code (which also integrates
a sandbox ... to eliminate those "plugin" problems that people were
complaining about -- on hlds_linux i think)

Steven Hartland wrote:
Fact is if you can come up with something static, I'll give you
and example where it falls flat on its face making totally the
wrong decision.

This is NOT a problem which has a static solution, any attempt
to do so would be a huge waste of time.

   Steve
----- Original Message -----
From: "Whisper" <[EMAIL PROTECTED]>

[ Picked text/plain from multipart/alternative ]
Surely it is not difficult to program into your Game Server Management
Systems a method for:

a)Determining the maximum amount of HLDS/SRCDS processes to be
allowed to be
spawned on a physical CPU/CPU Core

b)If CPU/Core already has a HLDS/SRCDS process running on it,
manually (via
your Game Server Management System) to set the processes affinity to
use the
next CPU/CPU Core

c)Wash Rinse Repeat

Hell, I am surprised many of you are not already doing this, since
not being
able to see this problem coming a mile off is naive. You would do it,
if for
no other reason than, if you have 2 x 32 player SRCDS and 2 x 16 player
SRCDS on a Dual Xeon for example, you don't want the 2 x 32 player SRCDS
processes sitting on 1 CPU and the 2 x 16 player SRCDS on the other
CPU. And
you all know being humans rather than a computer, that the obvious
optimal
solution is to ensure that the each CPU gets 1 x 32 player SRCDS and
1 x 16
player SRCDS and bugger off what Windows or SRCDS thinks how they
should get
allocated.

I don't know, maybe I am over thinking the problem or maybe some of
you are
over thinking the problem, but it does seem like the solution is not all
that difficult to achieve.


================================================
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

Reply via email to