-- [ Picked text/plain from multipart/alternative ] Well I guess if you don't know what servers you are running, and don't know how they run, and don't know what the normal operating parameters are for them, then yes, you will probably be making the wrong decisions, and that would be my own stupid fault for assuming you and those like you, would be aware of all of this when making your choices.
On 4/10/06, Steven Hartland <[EMAIL PROTECTED]> 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
