Same thing here, what was stable 128 before, now drags down to yellow
and orange time to time. Performance is far worse after that one
infamous patch.
-ics
Ejziponken - kirjoitti:
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]
<mailto:[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]
<mailto:[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]
<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
