* Simon Garner [2003-09-24 18:06]:
>
> I wouldn't expect to see Valve fix it until somebody can pinpoint that
> the problem is reproducable and quantifiable on X hardware with Y
> configuration running Z version of HLDS with ABC options. As long as we
> keep sending mixed messages to them, they won't know where to start
> looking, and nothing will be done.
>
*sighs* ... maybe the third message I'll actually send (the rest are
indefinetly postponed) ... anyway ...
Thoughts:
- People with P4 and HT, might want to use a kernel >= 2.4.17. Why?
Because it was the first kernel apparently that actually tried to exploit
HT. Idealy 2.6.x will perform better with HT's.
- People in general, you will want a kernel with pre-emptive and
low-latency patches. Why? Because .. read below.
- 2.6.x kernels will (and SHOULD), perform differently. Why? Lots of
things changed. Most important is the scheduler.
- People with SMP boxes, you'll want >= 2.4.20, play with the 2.6.x series
though. Why? .. see previous.
Since HT is like SMP, you will NOT notice a big difference unless the code
you are running, takes advantage of some form of threads. The HL engine does
_not_ do this. The SMP debate, has been hashed here many times before [1].
People running multiple servers on a box, should
notice a bit of a boost (over UP), assuming you are running a kernel >=
2.4.20, again play with 2.6.x.
A long standing (at least with 1.5) problem, is latency. Specificaly,
latency in syscalls, and u/nsleep. As a solution for 1.4/5, I replaced
sleep with yeilds in the server. As a result, pings were significantly
lower, but CPU usage reported by programs like TOP, were inaccurate[2].
There are other methods I've thought of since.
Given the changes in 2.6.x, it would be in ones best interest to look at
those scheduler changes. Specificaly, run-queue per CPU vs. one global
run-queue.
Previous to this message someone else offered to write a database to start
collecting more performance numbers. Curious if valve is doing this
internaly already.
As a side note, try renicing your servers and see if that helps. If so,
it may still be a scheduling/latency issue. For the _client_, changing the
priority to real-time, resulted in a good 20fps gain. No, the box is not
over loaded, and no, I don't have anything else running in the back.
[1] - Ideal code: each client has a thread, thread handles network IO,
making copious use of shared mem with main thread.
- Existing Code: *afaik* - one loop, client packets are processed as
received. No threads. Might explain why HP and LP's don't play well.
[2] - Top reports ambiguous data like "%90 cpu". Well, what is that
90 percent of? A pii's "90 percent", is a hella lot less cpu then an
Athlon XP 2400's. Same thing applies to the load.
Bottom line, unless you know what you are really seeing, and not looking
for eye candy, utils like top are useless to you. I don't know what HL's
own "stat" uses to measure CPU with, but it could be the same as top and
hense inaccurate.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
