Sorry for bringing this back to light from its creation over two years ago,
but this is STILL an issue. It's been only getting worse.
Thanks,
Kyle.
On Sun, Aug 31, 2008 at 3:36 PM, ics i...@ics-base.net wrote:
With CS Source, Windows servers have always performed better than Linux
ones.
Hey Neph,
You've tried using the fps_max command right?
Kyle.
On Sat, Aug 30, 2008 at 5:43 PM, Crazy Canucks [EMAIL PROTECTED]wrote:
Ah, I missed that. Nothing is ever as simple as it seems...
Drek
Nephyrin Zey wrote:
If you read my previous email, that was because of a plugin i had
I have, unfortunately it seems to have no effect.
+fps_max 0 results in absolutely no noticable CPU difference from +fps_max 60!
And to be clear, I'm aware that maybe using older kernels with slower
timerspeed and no HPET can result in *better* cpu usage, but it's
still quite high.
The main
With CS Source, Windows servers have always performed better than Linux
ones. Windows server can have server slots than Linux since CPU usage is
lower and tickrate more stable - for some reason. Hard to do good port
to Linux or its stiched in with iron wire, bubblegum and glue? Same
thing is
Am I the only one that thinks the almost 100% cpu load might have
something to do with the almost 4000 fps the server appears to be
running at?
Drek
Gary Stanley wrote:
At 03:36 AM 8/28/2008, Nephyrin Zey wrote:
I've complained before about how srcds chugs massive amounts of CPU, but
I sort of had that feeling too. I've been only running server with 100,
250 and 1000Hz kernels and those give 50, 120 and 500fps give or take.
So far 1000Hz gives best performance under heavy load (lots happening
in-game), rest just peak CPU to the roof time to time and cause glitching.
-ics
If you read my previous email, that was because of a plugin i had
running that i then removed and provided a snapshot without it, but
with the same problem.
I can't even get consistant 100FPS with 32 people in a SourceTV
server, on a 2.4GHz Xeon. That's the issue.
On Sat, Aug 30, 2008 at 11:29
At 06:59 PM 8/30/2008, Nephyrin Zey wrote:
If you read my previous email, that was because of a plugin i had
running that i then removed and provided a snapshot without it, but
with the same problem.
I can't even get consistant 100FPS with 32 people in a SourceTV
server, on a 2.4GHz Xeon. That's
At 06:59 PM 8/30/2008, Nephyrin Zey wrote:
If you read my previous email, that was because of a plugin i had
running that i then removed and provided a snapshot without it, but
with the same problem.
I can't even get consistant 100FPS with 32 people in a SourceTV
server, on a 2.4GHz Xeon. That's
Ah, I missed that. Nothing is ever as simple as it seems...
Drek
Nephyrin Zey wrote:
If you read my previous email, that was because of a plugin i had
running that i then removed and provided a snapshot without it, but
with the same problem.
I can't even get consistant 100FPS with 32
On Thu, 28 Aug 2008, Gary Stanley wrote:
At 04:51 PM 8/28/2008, Nephyrin Zey wrote:
I believe, and I could be wrong, that all recent versions of glibc call
gettimeofday as a virtual syscall, which means the context switching
doesn't occur.
IIRC, Only on x86_64. i386 doesn't move gtod
I'm interested in hearing more performance data points. I can't find
any useful information on the web aside from really bizarre
speculation from people who have no business commenting on server
performance.
On a Xeon 3060 (2 2.4GHz cores) with 2GB running CentOS 5, I can run,
at most two full
on behalf of 127001.org
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ryan Mannion
Sent: 28 August 2008 11:06
To: hlds_linux@list.valvesoftware.com
Subject: Re: [hlds_linux] [hlds] srcds CPU usage, again.
I'm interested in hearing more performance data
Your assumption on the bandwidth usage is about right. We have 2 around
half a day full 30 slot TF2 servers and in 2 months we have used 1,3 TB
of bandwidth (out). If i add external map download bandwidth to that, it
lifts that up a bit more. However, there is also a third server (CSS)
running
Bah, you're right, I still had my one plugin set to muck with FPS
settings. Here's the same deal with all plugins prevented from ever loading:
CPU InOut Uptime Users FPSPlayers
12.50 0.00 0.00 1 2 253.74 0
stats
CPU InOut Uptime Users FPSPlayers
At 03:36 AM 8/28/2008, Nephyrin Zey wrote:
I've complained before about how srcds chugs massive amounts of CPU, but
now that I've enabled SourceTV it's gotten absolutely absurd. Here is my
server idling, while my monitoring system polls it once a minute for CPU
usage. The server is *empty*, with
At 03:36 AM 8/28/2008, Nephyrin Zey wrote:
I've complained before about how srcds chugs massive amounts of CPU, but
now that I've enabled SourceTV it's gotten absolutely absurd. Here is my
server idling, while my monitoring system polls it once a minute for CPU
usage. The server is *empty*, with
Gary Stanley Wrote:
Have you tried an older kernel? I don't see those issues (at all).
However, I have plenty of hacks in place in kernel/time.c to make
gettimeofday() return for speed, no accuracy (saves a couple mpy and
divl cycles), and i don't use 2.6.26 series on my development stuff.
I believe, and I could be wrong, that all recent versions of glibc call
gettimeofday as a virtual syscall, which means the context switching
doesn't occur.
I'm not sure that fixing the overuse of gettimeofday() will solve all
these problems, I think there are just some serious issues with the
At 04:45 PM 8/28/2008, [EMAIL PROTECTED] wrote:
Gary Stanley Wrote:
Have you tried an older kernel? I don't see those issues (at all).
However, I have plenty of hacks in place in kernel/time.c to make
gettimeofday() return for speed, no accuracy (saves a couple mpy and
divl cycles), and i
At 04:51 PM 8/28/2008, Nephyrin Zey wrote:
I believe, and I could be wrong, that all recent versions of glibc call
gettimeofday as a virtual syscall, which means the context switching
doesn't occur.
IIRC, Only on x86_64. i386 doesn't move gtod into the shared page for
userland.
I'm not sure
At 04:51 PM 8/28/2008, Nephyrin Zey wrote:
I believe, and I could be wrong, that all recent versions of glibc call
gettimeofday as a virtual syscall, which means the context switching
doesn't occur.
IIRC, Only on x86_64. i386 doesn't move gtod into the shared page for
userland.
I'm not sure
22 matches
Mail list logo
