Hi 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 between 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. The 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 sep 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 larger 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 Csgo_servers@list.valvesoftware.com https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
