I’d be interested to know more about the performance, hopefully in the near
future I might want to create a 64 player server and I’d like to know if it’s
stable it self, if you can let me know more about how it handles with 50+
players I’d be thankful
😊
From: Kevin C
Sent: Friday, July 25, 2014 1:24 AM
To: [email protected]
It uses over a full core of the E3-1271v3, lots of spillover to networking
threads(upload is 3.6MB/s+ from my CS:GO server).
http://ark.intel.com/products/80908/Intel-Xeon-Processor-E3-1271-v3-8M-Cache-3_60-GHz
On 7/24/2014 8:22 PM, Matthias "InstantMuffin" Kollek wrote:
I wonder what the cpu usage would be like with 64 players.
InstantMuffin
On 25.07.2014 01:42, Kevin C wrote:
With the current boost to allow 64 player servers, the locked 80000 rate
doesn't seem to be enough. We are experiencing up to 20-30% choke with our
server at 64 active players.
We are using on the server side:
sv_maxrate 0
sv_minrate 128000
On my client(where I saw up to 20-30% choke):
rate 128000
This was on a 64 tick server. Here are some screenshots with 50-55 people alive
and playing.
http://steamcommunity.com/sharedfiles/filedetails/?id=290923067
http://steamcommunity.com/sharedfiles/filedetails/?id=290923051
http://steamcommunity.com/sharedfiles/filedetails/?id=290923035
Also, servers seem to be failing to respond to respond to queries used by
gametracker when going above 62 players. Player lists also fail to update in
HLSW when this happens.
On 7/24/2014 6:40 PM, Bruce Dawson wrote:
Thanks for the feedback. I now understand what happened:
· When net_splitpacket_maxrate was removed there was a fear that this
rate was now stuck at its old default of 15,000. It is not, it is currently
stuck at 80,000
· Also, the new rate of 80,000 is a bit lower than the 128,000 that
some server operators would set it to.
It sounds like the new behavior (despite being slightly lower than the old
peak) is okay and we’ll be careful about propagating the change to other games.
Let me know if my assumptions are wrong.
From: [email protected]
[mailto:[email protected]] On Behalf Of Kevin
Sent: Thursday, July 10, 2014 8:09 PM
To: [email protected]
Subject: Re: [Csgo_servers] net_splitpacket_maxrate
The current default is perfectly acceptable, and net_splitpacket_maxrate is no
longer needed in 99% of cases for CS:GO. We use it for TF2 and CS:S, and have
been for years.
While it is fine for CS:GO, I hope it doesn't get trickled down in its current
state to CS:S without more testing.
On 7/10/2014 10:11 PM, Jason Lee wrote:
Thanks Jesse, and many thanks also to Bruce, this is the most open dialogue
I've seen while lurking this mailing list.
The picture Jesse linked to is a perfect example of what I'd typically see in
net_graph under high load (lots of players/action etc), even though the
hardware (CPU, RAM, network) load of the server is normal the clients still
receive high choke.
On Fri, Jul 11, 2014 at 11:25 AM, Jesse Molina <[email protected]> wrote:
On 7/10/14, 14:36, Jason Lee wrote:
Like was mentioned earlier, many of us don't understand how or why, just that
this was the golden solution for high load/traffic servers.
Understanding the history of net_splitpacket_maxrate is important:
http://comments.gmane.org/gmane.games.fps.halflife.server/26272
Tony Paloma's post pretty much guaranteed that most administrators would be
playing with this feature. But unlike many of the other "turbo button" type
network configuration parameters, this one made a demonstrably positive
difference in game performance under common conditions.
The effect of this command on a 32-player TF2 server could be dramatically
positive. Without it, the server would artificially choke back traffic to the
detriment of the player experience while the network and CPU resources
inexplicably sat idle. Any scenario where a large amount of data was being
sent to clients could trigger this artificial limit.
http://www.sourceop.com/randomimages/net_splitpacket_maxrate/from_default_to_high.jpg
The new default is great, but this is one change that would have been good to
communicate given it's high usage in the non-Valve server hosting community.
Bruce, thank you very much for communicating with us regarding this issue.
_______________________________________________
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
_______________________________________________
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
