I agree as well, I just assumed my dated server could no longer handle anything above 20 players.
Hopefully this gets resolved soon :) On Tue, Jan 14, 2014 at 1:10 AM, Ejziponken - <[email protected]> wrote: > I can confirm that running CSGO-servers on linux since a patch from last > year is a bad idea. We had to lower player-slots from 32 players with > stable 128tic to 20 players to get the stable 128tic. > > > > ------------------------------ > Date: Mon, 13 Jan 2014 23:02:13 -0500 > From: [email protected] > To: [email protected] > Subject: Re: [Csgo_servers] Valve bug report regarding XEON cpus and csgo > servers > > > Hello, > > Does anyone have a copy of the old server binaries that do not require the > new instruction sets as mentioned by the OP? > > If so, could you please share? I'd like to test this with our servers. > > Thank you, > cyberdeath > AtomicZone Lead Server Admin > On Jan 12, 2014 11:49 AM, "Marc Leuser" <[email protected]> wrote: > > I can confirm that the linux performance is pretty poor, i'm running a > single 10 slot server on an E5-2620 (2 GHz) and the var is above 1.5 most > of the time, even if there's only 4 players on the server. I've noticed > that it doesn't matter if I give 1 or 2 CPU cores to the process, it won't > use more than one anyway. I've also given the process the highest possible > priority without any effect. > Even with 1 Player i can see an average of 30% CPU usage which i think is > really too much. We're talking about a gameserver running almost > exclusively on that machine. > > Are there gurus out there who can tell me if there's any option besides > using some fancy high-end i7 CPU to host one(!) solid gameserver with var > <1.0 and 10 players? > > > greetings > > Am Sonntag, 12. Januar 2014 16:57 CET, Egner <[email protected]> > schrieb: > > > H i valve, > I will try to let you guys know about a nice bug in your srcds application > regarding XEON cpus and 128 ticks. > First of all will I say that i am not especially good in English so please > be kind. I will describe exactly what I have figured out on my own. > Well, the problem stated when valve send out a update regarding the srcds > application and changes the linux application and windows application > 2013-11-15 I believe. > > What have then happened after the update? Well the 128 tickrate have been a > bit unstable also the var value from the server have reached from low value > to higher. And also has result in a higher cpu usage for more players and > less. > Then I have an option to work with some different kind of processors that > have a newer version of CPUs build. > My test environment : > > *#1 server > Intel Xeon E5-2620v2 processor* > > *#2 server > Intel Xeon E5-2420 processor* > > *#3 server > Intel i5-4570S hasswell (my own server home)* > > *#4 server > Intel Xeon x5660 (older arch)* > > My test I use those following operation systems: > 1. Linux Debian Weezy (64 bit) > 2. Windows 2012 server (64 bit) > 3. I use the same server config on all servers. > > Well, first of all I have read about people that say that the windows will > works mush better with 128 tickrate against linux. But after my results in > this test I will say that the linux still is a little bit better then > windows. > > I start with the Intel Xeon E5-2620v2 with 32 players with bots. > My first result was: > With Linux the var value was about 1.0 - 3.0 and the tickrate was unstable > and the sv value blinking orange but is not going to red. The server was > playable but not more than that. The hitbox wasn’t fun! > With windows on the same setup I got var on the same value as the linux > does, and the sv value was red its freezing to the death. (that wasn’t > playable) > Linux use 100% -133% cpu usage on the process srcds_run but the system not > even going over 5% cpu of the whole systems capacity. > Windows use 30% on the process srcds_run but still lag as hell. > Ok the result here is that the machine is not possible to use all the > capacity of the cpu is like a wall have been created. > Well we going forward, so now we going for the #2 server setup. So then we > look at the results. > With linux the var value was about 0.8 – 2.8 and the tickrate was unstable > and going between orange and red. That wasn’t playable. > With windows the var value was almost the same as the linux do. So that was > not possible to play. > And was the problem with the cpu this time, the process use 135 % cpu on > process but the system is like sleeping. > And the different here was that cpu was 45% on cpu usage on windows betw > een > the newer E5-2620v2 setup so it goes a little bit harder. > Then we move on to the server 3 setup. > I was quite surprised when I comes to the hasswell setup, because as soon > as > I join the server with 4 – 8 bots and the var value was about 0.8 and the > ticrate was 128 the whole time. > Then I believe that that may also be able to handle 32 players. So I decide > to bring on 32 players on my server with linux and windows setup. And whola > the process goes like a sunny day! > Even if the process on top use 135% of cpu in the process, and the server > use about 30% of cpu total the 32 players works smoth without tickrate > drop. > So then I belive that the higher gigahertz does the thing, so I decide to > try with server 4. Whish has 2.8 Ghz processor. Which is quite higher than > my server #1 and server #2 setup? > And then to the result, it was so bad so the players can even go in spawn, > both in windows and linux. T he process does like they all do 135% on linux > and about 33 % cpu usage on windows. > The var value was 2.9 and the sv value was RED 5 -15. > So then I have to start from the beginning again, because the Gigahertz > wasn’t a problem! So then I take a deeper look in what cpu instructions my > Haswell cpu use. > I decide to look on the cpu instructions on both server #1 and server #2 so > I have something to compare with. Well to be clear all servers have the > same > behavior. So what is the different here? > > *This is my cpu instructions from server #1. (E5-2620v2)* > > flags: fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht > syscall nx lm constant_tsc rep_good nopl pni pclmulqdq ssse3 cx16 sse4_1 > sse4_2 x2apic popcnt tsc_deadline_timer aes f16c rdrand hypervisor lahf_lm > ida arat pln pts dtherm fsgsbase erms > > *And this have server #2. (E5-2420)* > > flags: fpu de tsc msr pae cx8 se p cmov pat clflush mmx fxsr sse ssss ht > syscall nx lm constant_tsc rep_good aperfmperf pni pclmulqdq ssse3 cx16e4_1 > sse4_2 x2apic popcnt aes hypervisor lahf_lm ida arat > As you can see here is that a little different between server #1 and server > #2, but them have also the same type of issue so we move to that server > that > works great. > * > Server #4 (I5 - 4570S)* > > flags: fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht > syscall nx lm constant_tsc rep_good nopl pni pclmulqdq ssse3 fma cx16 > sse4_1 > sse4_2 x2apic movbe popcnt tsc_deadline_timer aes f16c rdrand hypervisor > lahf_lm abm ida arat pln pts dtherm fsgsbase erms > > As you can see did this server have an instruction with name : *abm* and > *fma.* > If we google this instructions are this part of AMD cpus. So what I am > think > is that the server use AMD binaries. > Link : http://en.wikipedia.org/wiki/FMA_instruction_set > Link : http://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets > > In 1.6 can you see if a server use a hlds_amd64 binaries or hlds_i686 > binaries. But in the new srcds you cant! The name is only srcds_linux. > I think that the server binaries from my hasswell have to be located as an > AMD cpu. Then I believe that the AMD have a much better server binaries > then > intel has but I can be wrong here! > > With this I hope Valve will take a look in to my post and then take a look > from there development team what them can done wrong since they sending out > the new update 2013-11-15. > I have also try to roll back the srcds from 2013-11-15, and with them > running the server is using alot less cpu then the new version of binaries > does, even if a player is online or not! > I have also take a look of the binaries in csgo-ds/bin folder and the > different between the working version and the bad version is that the size > is lar ger on the new version, is about 1 mb more and one of the big > changes > is in the srcds_linux version and dedicated.so files. > If you want more information regarding this valve, please contact me! > > /thanks Egner > > > > > -- > View this message in context: > http://csgo-servers.1073505.n5.nabble.com/Valve-bug-report-regarding-XEON-cpus-and-csgo-servers-tp6091.html > Sent from the CSGO_Servers mailing list archive at Nabble.com. > > _______________________________________________ > 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 >
_______________________________________________ Csgo_servers mailing list [email protected] https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
