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. 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 with OB engine. If SSE2 is disabled, its propably for a reason > but i doubt you, me or anyone else will get any kind of direct reply > from Valve in matters that fall into commercial secrets and their Source > engine is one of them. I doubt they will talk about how it works - in > full detail. Funny thing is that most servers that run Source engine are > on Linux - not Windows. > > -ics > > > Nephyrin Zey kirjoitti: > > 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 issue: > > why does 'boosting' on windows (all linux servers seem to be > > 'boosted') seem to cause a 10x drop in efficiency? A 'unboosted' > > server gets 66fps on a tiny amount of CPU. Yet my server can reach > > 66fps for brief moments when they're heavily lagged, chugging 100% > > CPU! For this brief instance, what is my server doing that is taking > > up 4x the CPU of an unboosted server, without a single additional > > frame per second? > > > > And i've used host_profile to look at all these FPS readings, it's not > > just the broken stats FPS that's misleading me. > > > > Also: > > r_sse2 reports SSE2 is disabled on linux servers. Bug? > > > > - Neph > > > > On Sun, Aug 31, 2008 at 1:30 AM, Kyle Sanderson <kyle.l...@gmail.com> > wrote: > > > >> Hey Neph, > >> You've tried using the fps_max command right? > >> > >> Kyle. > >> > >> On Sat, Aug 30, 2008 at 5:43 PM, Crazy Canucks < > crazy_canu...@rogers.com>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 > >>>> 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 AM, ics <i...@ics-base.net> wrote: > >>>> > >>>> > >>>>> 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 > >>>>> > >>>>> Crazy Canucks kirjoitti: > >>>>> > >>>>> > >>>>>> 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 > >>> > >>>>>>>> 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 is autorecording, but turning this off has a small > effect. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> CPU In Out Uptime Users FPS Players > >>>>>>>> 99.90 0.00 0.00 1556 14 3831.42 0 > >>>>>>>> rcon from "75.125.209.6:38438": command "stats" > >>>>>>>> CPU In Out Uptime Users FPS Players > >>>>>>>> 11.00 0.00 0.00 1557 14 3378.38 0 > >>>>>>>> rcon from "75.125.209.6:38442": command "stats" > >>>>>>>> CPU In Out Uptime Users FPS Players > >>>>>>>> 23.80 0.00 0.00 1558 14 3802.28 0 > >>>>>>>> rcon from "75.125.209.6:54402": command "stats" > >>>>>>>> CPU In Out Uptime Users FPS Players > >>>>>>>> 99.90 0.00 0.00 1559 14 1782.53 0 > >>>>>>>> rcon from "75.125.209.6:54406": command "stats" > >>>>>>>> CPU In Out Uptime Users FPS Players > >>>>>>>> 9.00 0.00 0.00 1560 14 673.40 0 > >>>>>>>> rcon from "75.125.209.6:54410": command "stats" > >>>>>>>> > >>>>>>>> A process monitor shows this server idling at 25-28% of the core > it's > >>>>>>>> assigned to. > >>>>>>>> > >>>>>>>> I'm not doing any special boosting, but i am using a 2.6.26 kernel > >>>>>>>> (which has the new cpu sched, and such). I've tried 300hz and > 1000hz, > >>>>>>>> tickless, preempt on off, and realtime kernels, and found that > they > >>>>>>>> > >>> all > >>> > >>>>>>>> have relatively minor effects on CPU usage. Turning off high > >>>>>>>> > >>> precision > >>> > >>>>>>>> timers + turning kernel hz to 100, so the system cannot achieve > >>>>>>>> > >>> higher > >>> > >>>>>>>> than 100fps, results in moderately less CPU usage, and a > performance > >>>>>>>> > >>> hit. > >>> > >>>>>>>> So what am I going to do? The windows srcds has moderately better > CPU > >>>>>>>> usage, but I run a quadcore linux system that also provides other > >>>>>>>> services, and can't easily switch. > >>>>>>>> > >>>>>>>> More worrying: the windows srcds 'unboosted' uses TINY (like <20% > of > >>>>>>>> > >>> a > >>> > >>>>>>>> core FULL) amounts of CPU. It gets 66fps, sure, but my servers dip > as > >>>>>>>> low as 66fps when they're at 100% bloody CPU usage! > >>>>>>>> > >>>>>>>> Is this ever going to be looked at? Am I doing it wrong? > >>>>>>>> > >>>>>>>> - Neph > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> To unsubscribe, edit your list preferences, or view the list > archives, > >>>>>>> > >>> please visit: > >>> > >>>>>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> To unsubscribe, edit your list preferences, or view the list > archives, > >>>>>> > >>> please visit: > >>> > >>>>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > >>>>>> > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> To unsubscribe, edit your list preferences, or view the list > archives, > >>>>> > >>> please visit: > >>> > >>>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> To unsubscribe, edit your list preferences, or view the list archives, > >>>> > >>> please visit: > >>> > >>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> To unsubscribe, edit your list preferences, or view the list archives, > >>> please visit: > >>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > >>> > >>> > >> _______________________________________________ > >> To unsubscribe, edit your list preferences, or view the list archives, > please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > >> > >> > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
