Well today I tried not locking each server to a core and wow, thats bad.the var spikes and goes red every few seconds when its not locked.
> Date: Tue, 17 Feb 2015 15:35:03 -0800 > From: [email protected] > To: [email protected] > Subject: Re: [Csgo_servers] cpu usage > > It isn't the case that there's a "regular core" and a "HT core" when > hyperthreading is enabled -- that's not how it works. Instead, each > physical core is split into two virtual cores that have equal footing. > If you use only one of those two cores (it doesn't matter which one), > then you achieve the same performance as if you hyperthreading were > disabled. If you use both of them, then they share the resources of the > physical core, ending up with slightly higher performance than if the > same processes were run on a single physical core with hyperthreading > disabled. > > Modern OSes (including Windows) recognize the way that hyperthreading > works and will not put two intensive processes on the same physical core > unless the system is heavily loaded. If the system is heavily loaded, > that's when you'll be happy to have hyperthreading enabled, because you > can squeeze out just a bit of extra performance. > > So: > > - Don't disable hyperthreading on a modern CPU and modern OS, as you'll > see lower performance. > - Don't try to set your own affinities for processes, because each > process may have more than one thread -- that you want to be on > different cores -- and because the OS generally does a very good job of > balancing them (and factoring in hyperthreading). > > (Old-style P4 SMT worked differently, but there isn't too much sense in > addressing that, since nobody should be running anything that old with > CS:GO!) > > -John > > On 2/17/2015 1:54 PM, ics wrote: > > While SRCDS these days is somewhat multithreaded, it is best to keep > > HT OFF. The main process, the core one, if that goes to the HT core, > > it will not run as good (lags) as on regular core. Also when the main > > process peaks at 100% cpu, it's game over and lag spikes occur, even > > on regular core. > > > > So if you have weak CPU, and you overload it thinking "i have 4 cores, > > i can run 50 slots 128tick CSGO", then you're out of luck because the > > main process will hit the 100% and the other cores do not help in that > > case. I'm not sure what is running on other processes but i assume > > particle system or physics calculation. > > > > -ics > > > > Daniel Barreiro kirjoitti: > >> Possibly. As far as I know, HT no longer causes problems with SRCDS, > >> but I could be wrong. > >> > >> If you want to play with some cvars: > >> > >> host_speeds : 0 : , > >> "launcher" : Show general system running times. > >> host_thread_mode : 1 : , > >> "launcher" : Run the host in threaded mode, (0 == off, 1 == if > >> multicore, 2 == force) > >> host_threaded_sound : 0 : , > >> "launcher" : Run the sound on a thread (independent of mix) > >> host_threaded_sound_simplethread : 0 : , > >> "launcher" : Run the sound on a simple thread not a jobthread > >> host_timer_report : cmd : : Spew > >> CPU timer jitter for the last 128 frames in microseconds (dedicated > >> only) > >> > >> > >> > >> Most of these are hidden so you'll need to use sourcemod to change > >> them. Not sure if the sound ones apply (doubt it) but they're there. > >> > >> Some other cvars to play with: > >> > >> > >> net_queued_packet_thread : 1 : , > >> "launcher" : Use a high priority thread to send queued packets > >> out instead of sending them each frame. > >> net_threaded_socket_burst_cap : 256 : : Max > >> number of packets per burst beyond which threaded socket pump > >> algorithm will start dropping packets. > >> net_threaded_socket_recovery_rate : 6400 : : > >> Number of packets per second that threaded socket pump algorithm > >> allows from client. > >> net_threaded_socket_recovery_time : 60 : : Number > >> of seconds over which the threaded socket pump algorithm will fully > >> recover client ratelimit. > >> sv_threaded_init : 0 : , "sv", > >> "launcher" : > >> > >> threadpool_cycle_reserve : cmd : : Cycles > >> threadpool reservation by powers of 2 > >> threadpool_reserve : 0 : , > >> "launcher" : Consume the specified number of threads in the > >> thread pool > >> threadpool_run_tests : cmd : : > >> > >> cl_clockdrift_max_ms : 150 : , "cheat" > >> : Maximum number of milliseconds the clock is allowed to drift > >> before the client snaps its clock to the server's. > >> cl_clockdrift_max_ms_threadmode : 0 : , "cheat" > >> : Maximum number of milliseconds the clock is allowed to drift > >> before the client snaps its clock to the server's. > >> > >> > >> > >> Most of these are tweaked and then hidden for a reason, so if you do > >> adjust them expect instability/potential worse performance. > >> > >> Here's a full list of server cvars + the hidden ones. I did my best > >> to remove any plugin cvars but there may be a few I missed. > >> http://pastebin.com/mnj7GXUF > >> > >> On Tue, Feb 17, 2015 at 4:05 PM, Ejziponken - <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> And if the CSGO servers are using multithreading, should HT then > >> be ON for best performance? > >> > >> ------------------------------------------------------------------------ > >> Date: Tue, 17 Feb 2015 16:01:26 -0500 > >> From: [email protected] > >> <mailto:[email protected]> > >> To: [email protected] > >> <mailto:[email protected]> > >> Subject: Re: [Csgo_servers] cpu usage > >> > >> > >> What are the specs of the server? Graph isn't very helpful without > >> the full details which are lost in another thread. > >> > >> On Tue, Feb 17, 2015 at 3:58 PM, Kevin C <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Starting a new thread because the other one got too big. > >> > >> To simplify this, here is a CPU usage graph for the #1 CS:GO > >> server. 64 slot @ 64 tick: > >> http://i.gflclan.com/Screenshot_02-17-15-15-57-08.png > >> > >> _______________________________________________ > >> Csgo_servers mailing list > >> [email protected] > >> <mailto:[email protected]> > >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > >> > >> > >> > >> _______________________________________________ Csgo_servers > >> mailing list [email protected] > >> <mailto:[email protected]> > >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > >> > >> _______________________________________________ > >> Csgo_servers mailing list > >> [email protected] > >> <mailto:[email protected]> > >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > >> > >> > >> > >> > >> _______________________________________________ > >> Csgo_servers mailing list > >> [email protected] > >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > > > > > > _______________________________________________ > > Csgo_servers mailing list > > [email protected] > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > > > _______________________________________________ > Csgo_servers mailing list > [email protected] > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
_______________________________________________ Csgo_servers mailing list [email protected] https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
