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
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)
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)
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 wa
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.
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*, wit
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*, wit
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
12
Neph what OS are you running,, and why (if I am reading your post right) is
your stats reporting a FPS of 3831.42 ?
have you tried not setting an affinity to any one core?
~kennycom
- Original Message -
From: "Nephyrin Zey" <[EMAIL PROTECTED]>
To: "Half-Life dedicated Win32 server ma
Our xeon 3060 with 4Gb mem. FC6, is running 4 dod:s servers, 32 slots + 20
slots + 16 slots + 12 slots with sourceTV.
The scrim-server with sourceTV have been running for 2 month now and is now
using 8% cpu idling.
The other 3 servers is using 3-4% idling each !
So I have no problem with 100% cp
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
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, SourceTV demo recording, no
players connected arena_badlands
uname -a:
Linux orion 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686
GNU/Linux
Running ubuntu feisty 32-bit
11:28:02 stats
11:28:02 CPU InOut Uptime Users FPSPl
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 32-
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 no bots, with just SourceTV on.
SourceTV
15 matches
Mail list logo
