Re: question about frequency timer
Wojciech Ziniewicz wrote:
2008/6/5 Giacomo A. Catenazzi <cate@debian.org>:
Anyway, why do you poste in debian-isp list?
apparently question is concerning debian stock kernel, it came to me
while developing hosting system for internet multiplayer games like
counter strike etc. With timer of 1000Hz and dynamic ticks , servers
are about 50% more stress capable.
Ok. Game servers use a lot more CPU then normal servers.
The "normal" servers, could give answer in few millisecond,
so in a server with 100Hz or 250Hz, you don't have scheduler
and cache overhead: the process go in a "waiting" state
before kernel will call the scheduler.
This is optimal and fast "normal" server (web, dns, ssh, ...).
On some dynamic script (but if the process doesn't
stop before, because disk, net or SQL queries),
the scheduler could be called few time.
With 1000Hz, the processes is rescheduled a lot more time,
which is not optimal on web/dns/... servers.
This is the main reason of 250Hz: a good trade-off between
normal server use and desktop interactiveness.
On desktop the optimal value is 1000Hz, because
there are a lot more process running, but
user still want interactivity.
Take as example: 100Hz, and 5 process running,
it would take 1/20 of second before an application
could run, but 1/20 of second could be noticeable.
250Hz is enough good, if user doesn't have
a lot more process running.
You have a special case, with a lot of CPU usage, and
possibly less "waiting state" from SQL or other sources,
so a special setting could be better.
But you have a special case, so I don't think should
be addressed by Debian kernel.
Maybe you should tweak other parameters of
scheduler.
If you have time and resources, you could
benchmark some of latest vanilla kernel
and send data to Linux kernel mailing list.
They are tweaking/changing scheduler, and
they kernel people are happy to see
strange behavior (an 50% more output
on stress case are very interessant).
ciao
cate
Moreover with this setting in kernel, servers are more reliable and
less "lagging" (still talking bout those css server) .
And the most interesting part : I've tried this setting on www server
and bgp peer routing about 40-100 mbits and everytime the latency is
better (i mean lower) , ram usage become minimally lower (why ? ) and
tottaly enigmatic for me - entropy is about hmm... 10-100 times bigger
(depends on server) ?
Generally recompiling the kernel for those machines in the manner i've
mentioned change almost every parameter in the better way. So what
problems can I expect ?
regards.
p.s. every statistics were taken on 32bit machine from munin-graphs
Reply to: