Some final words as this is obviously leading no where:
----- Original Message -----
From: "Chance Sullivan" <[EMAIL PROTECTED]>
A white paper would be a good idea, Also a nice white paper on why
XP is better than 2003 for running game servers would be good as well.
No one is saying XP is better it is so a mute point.
I cant see what you are trying to say here; OS's have
versions? I think we are all aware of that :P
Versions would be the version of the programs and libraries you mentioned
above.
Thats perfectly obvious, if they where the same they wouldnt be
different :P
I mistated this, I was thinking one thing and saying another. If it's
running as a service, then it's not using the Graphics hardware and PCI bus
for any of the graphics, IE the HAL is not used as well, leaving the
resources free for running processes.
So why not just minimise them this would produce the same
effect according to your logic.
Actually there are few or no factors which influence an
application being able to run as a service, ever heard or
svrany / instsrv?
Being more precise I was referring to applications that require user
interaction to run, using srvany/instsrv will not solve that problem without
adding additional overhead. Some Applications run well sith srvany/instsrv
and some do not. Fortunately most games work well with it enough for us to
use them to a point. However using either of those is not a very good way to
do so as it doesn't close the application properly and can leave system
memory allocation fragments/unclosed filehandles and such. There are other
methods to get game servers running as a service.
As far as "using either of those" goes you clearly don't know what they
are as instsrv is used to create service's and srvany to run any application
as a service ( created by instsvr ) so you could never use instsrv to run a
game server as a service as you state.
Using svrany will never leave memory allocated or unclosed filehandles,
dont know where u got this impression.
You can even run an application that requires user
interaction as a service, "Allow interaction with desktop" anyone?
Even if this where a restriction ( which it isnt ) it leaves
about 99.99% of servers out there; BHD and JO are the only
two that spring to mind which required user interaction to
start. But from what your saying all the others can perform
better simply by running as a service? I think NOT!
I think so, and the reason is because it's assigned to the Service Control
Manager as the parent process that controls them.
I think you are under the total missunderstanding that the
SCM does anything other than monitor the processes it started,
to ensure they are running. It has now effect on sheduling
and hence performance what so ever.
I am thinking in the realm of 2-4GB, so we are close there.
So you put 4Gb of ram in your game server machines, nice
but waistful :P
Now back to the real stuff. The question was if it does NOT use it?
Why that specific question? Because if it did use it you
would need either a seperate binary per OS or runtime checks
to make use of it.
Since we are primarily talking about Fiber's here and given
the fact that game servers dont even use threads to any great
extent chances of them making use of and hence gaining
benefit from them is so small its untrue. Hence the answer
your looking for was NO plain and simple.
The answer is that even if they do not use it, they benefit from the OS
using it to prioritize the processes it runs which in turn is game servers
in this topic, if it's handed over to SCM in windows or the appropriate
process, or processes in Unix.
They would only benifit if they OS ( kernel ) was using
significantly less machine resources to do they job it did
previously without them. I'd put it to you thats not the case
as otherwise MS would be shouting from the houses that 2k3
10% or more quicker at running all your apps.
They don't use it directly, but indirectly, gaining indirect benefits. Also
as was said before, the benefit is not there unless your running more than a
few(2-3 roughly) instances, Also, saying that an application can't benefit
from new features that it doesn't use, but the OS uses on the application,
is not a very sane statement, as the OS controls the application in the
instances we are talking about. As far as my ability to use analagies, I
don't think there is a problem with it at all.
Again so why isn't MS shouting about this nice performance
increase?
Also, not all game servers are single threaded, some use between 2-6
threads.
They do? Which? ( I'm talking real work threads here not basically
idle threads )? UT for example uses a seperatethread to do DNS
lookups but since they are so infrequent event doubling the
performance ( which your not doing to see ) would have no
persevable effect on the servers performance.
Everyone has their opinion and is entitled to it and your welcome
to think what you like as I am.
Yes you are, no one's saying your not but when you take those
opinions and give others advice based on them; when they are
unsubstansicated its like chinese whispers. People start to
believe its true just because it was said, even though its not
actually so.
As far as continuing the discussion please do so if you have
any references to any real concrete information on why running
a game server on Windows XP would achieve better performance
than one run on Windows 2003, otherwise I think we can both
agree to disagree on this topic.
I dont need to as I've never claimed XP is better. My entire argument
its they are so similar in performance that there is no justification
in spending the additional money on 2003 Server when XP Pro
will do just as good a job, just like buying that 6800 to run vi
is pointless.
Steve / K
================================================
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
