Thread: TPG CSGO Cloud Server needs play testing

I noticed one single hiccup that was a bit of lag. Could of been client side. I don't know. Ping is more than acceptable but I am not hardcore. Kanati, how about you hop in and try the server yourself??

Originally Posted by Kanati8869

(It's not a problem with WINDOWS from what I've been able to gather. It's a problem with valve not bothering to optimize their windows based servers).

Huh, quite on the opposite... Its a limitation of the maximum scheduled time a thread can be allocated in winodws. Before you bring up other games, ill counter with the source engine being much more highly centric to hit registation and having significantly higher simulation ticks per second than most other games and thus the problem only really seems to surface with source based games. Futhermore, the way windows allocates memory is TERRIBLE, it has a few benefits but for anything that runs for a long period of time, its horrible!


@Broc, excellent. Currently, the server is running on 1/4 the resources that the csgo server on hypernia windows box, uses .


When I get home Ill make all the changes mentioned and likely boost the box with another cpu...

@Higher tick request...If the server running great now, why do you need higher tick rate?

Hmmm..

Tablet-

Originally Posted by Bunni

Huh, quite on the opposite... Its a limitation of the maximum scheduled time a thread can be allocated in winodws. Before you bring up other games, ill counter with the source engine being much more highly centric to hit registation and having significantly higher simulation ticks per second than most other games and thus the problem only really seems to surface with source based games. Futhermore, the way windows allocates memory is TERRIBLE, it has a few benefits but for anything that runs for a long period of time, its horrible!

I am going to HAVE to counter with other game servers. If optimal play can be achieved with lesser network coding on other game engines then there is absolutely no reason why valve can't do the same. I have windows host boxes that swap vm's in and out all day long with uptimes of over a year. I have SQL servers that have uptimes far longer than that (a few of which I haven't set memory limits on so SQL will take as much as the vm wants to give it). So I stick with "valve has no interest in optimizing their shit."

@Higher tick request...If the server running great now, why do you need higher tick rate?

Hmmm..

Obviously....

Nigel Tufnel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and...
Marty DiBergi: Oh, I see. And most amps go up to ten?
Nigel Tufnel: Exactly.
Marty DiBergi: Does that mean it's louder? Is it any louder?
Nigel Tufnel: Well, it's one louder, isn't it? It's not ten. You see, most blokes, you know, will be playing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar. Where can you go from there? Where?
Marty DiBergi: I don't know.
Nigel Tufnel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?
Marty DiBergi: Put it up to eleven.
Nigel Tufnel: Eleven. Exactly. One louder.
Marty DiBergi: Why don't you just make ten louder and make ten be the top number and make that a little louder?
Nigel Tufnel: [pause] These go to eleven.

I have had silky smooth gameplay on the new server every time I play on it. It's gotta be something different in the server config IMO.

I'm ready to concede that it's a windows vs linux thing but not for the reasons the rodent says.

Originally Posted by Kanati8869

I'm ready to concede that it's a windows vs linux thing but not for the reasons the rodent says.

At least set the new server to the exact same server config to confirm whether or not the lag returns.

It could also be a network stack issue in windows vs. linux. You may want to check the different network settings between the two to see if there would be a difference as well.

Originally Posted by Bunni

@Higher tick request...If the server running great now, why do you need higher tick rate?

I suppose we should have clarified. The test server with 64 tick isn't lagging, but that doesn't mean it doesn't have the issues inherent to 64 tick. Most notably interp related, but also noticeable in simply shooting players.

Originally Posted by Kanati8869

I am going to HAVE to counter with other game servers. If optimal play can be achieved with lesser network coding on other game engines then there is absolutely no reason why valve can't do the same.
...
So I stick with "valve has no interest in optimizing their shit."

Eh, other engines do not, you have to examine target audiences of games you are referring to. Most engines are a farce through network prediction and lag compensation. For fun times, such methods are irrelevant and unnoticeable save the occasional rage death (e.g. "enemy shot me at the corner, when i had already walked around the corner": laggy hit box). However at high levels of competitive play, these methods almost always yield games to fail and die in the competitive scene (e.g. BF*,TF2 (see later for explanation of other source engine games vs CS*), L4D* (among many other reasons),etc ). Beyond compression, less player network data means less precise player movement, means opportunity for resulting chaos such as rage deaths = huge nono for competitive play. If you look at the list of FPS's that see high level competitive play, you'll notice the list is extremely small.

High level competitive leagues only host current games where performance is not a concern. Games with low priority networking yield disturbingly large number of lag related complaints when matches are disputed (becomes radically more apparent when prizes are on the line), take my word for it (I have years of experience admining for competitive leagues). WCG 2012 hosted only one FPS (crossfire, managed hosting) out of 5 hosted games. Look at ESL (Go4 is their mid tier; IEM, EMS one, and ESL Pro are their top tier, notice only CSGO is supported), Intel extreme masters which last supported FPS was counter strike, etc.

For every day fun, games with optimized networking traffic are fine. However, CS* is a game that explicitly targets the highly competitive scene. More importantly CSS and CSGO feature flavors of the source engine that remove the hard-coded tick, fps, and rate limits that HL2DM, L4D*, and TF2 see, for the explicit purpose of targeting the highly competitive scene.


Valve does optimize their cs* server engine -thats the point-, they optimize for extreme, high performance.

Originally Posted by Kanati8869

... I have windows host boxes that swap vm's in and out all day long with uptimes of over a year. I have SQL servers that have uptimes far longer than that (a few of which I haven't set memory limits on so SQL will take as much as the vm wants to give it). So I stick with "valve has no interest in optimizing their shit."

Exactly, you have to use VM's because windows is to clumsy to manage the memory of the virtualized processes itself (hearing how much you use vm's I doubt i need to explain how vm's work with memory) . Linux server up-times are expected to be months and frequently years, hardly warrant celebration like one would see for the same up-times on a windows server.



But this is all tangential to the main topic. I apologize, but the above is related to the below.

Originally Posted by Kaido

We had a full server for a few rounds on dust 1 last night with no lag, but the map made people leave and attempt to prime the regular server resulting in both servers eventually being empty. I suggest taking out certain maps out of the rotation just so people don't leave for now, like dust1, vertigo, assault, office etc... Other than that here is what I gathered.

DERP! Woops! Thought I had copied the maplist over... map cycle currently is:

Code:

cs_italyde_dust
de_aztec
cs_office
de_dust2
de_train
de_inferno
de_nuke

dust1 is a given removal, but no office? Guess things have changed since css Alright, I've removed dust1 and office

Originally Posted by -Lazarus-

At least set the new server to the exact same server config to confirm whether or not the lag returns.

It could also be a network stack issue in windows vs. linux. You may want to check the different network settings between the two to see if there would be a difference as well.

They are, copied and pasted from one to the other (more or less, cleaned up a lot), save the tickrate, metamod, and sourcemod (both will be installed once we boost the tick and still see no lag). Networking, hmmm... maybe, personally, I'd wager it was cpu priority related. When I was testing out the csgo cloud server, I had directly copied the config files and thus the 128 tick-rate... I saw the exact same lag that the hypernia csgo windows server sees and could only remedy it by dramatically increasing the process priority of the csgo server on the cloud box... Though I dropped the tickrate back down so we could get a good resource footprint for source games...

Originally Posted by Kaido

....
...
- Rates are not being forced. This shouldn't really be an issue since most players will have proper rates set or at least have default Valve rates which are meant for 64 tick servers, but most servers force proper rates. I was able to connect with crappy rates which made the game play on the server appear extremely laggy.

Hmmm, was it a sourcemod mod that forced the rates? Isn't there a cvar for max and min rates for the server? Yeah, servers set to:

Code:

"fps_max" = "600" ( def. "300" )                                                 - Frame rate limiter
"sv_client_cmdrate_difference" = "20" replicated                                 - cl_cmdrate is moved to within sv_client_cmdrate_difference units of cl_updaterat
"sv_maxrate" = "128000" ( def. "0" ) min. 0.000000 max. 128000.000000 replicated - Max bandwidth rate allowed on server, 0 == unlimited
"sv_mincmdrate" = "20" ( def. "10" ) replicated                                  - This sets the minimum value for cl_cmdrate. 0 == unlimited.
"sv_minrate" = "10000" ( def. "5000" ) min. 0.000000 max. 128000.000000 replicated - Min bandwidth rate allowed on server, 0 == unlimited
"sv_minupdaterate" = "10" replicated                                             - Minimum updates per second that the server will allow

CC'ed from hypernia... Do these need to be changed? Or was it a sourcemod plugin that forced rates?

Originally Posted by Madmax (Grape)

I suppose we should have clarified. The test server with 64 tick isn't lagging, but that doesn't mean it doesn't have the issues inherent to 64 tick. Most notably interp related, but also noticeable in simply shooting players.

Originally Posted by Kaido

....
- 64 tick. Servers with this tick rate should run smoothly without a doubt, the real test will be 128 tick, or even 102.4 if we have no other choice.
- Rates are not being forced. This shouldn't really be an issue since most players will have proper rates set or at least have default Valve rates which are meant for 64 tick servers, but most servers force proper rates. I was able to connect with crappy rates which made the game play on the server appear extremely laggy.

Hmmm, well the kicker is that in doubling the tickrate we radically increase the amount of cpu and bandwidth the server will need...

Though, of course after the giant speech above about performance, we should have a high performance box tailored for the cs community...

Alright, tickrates gonna go back up and Ill add another cpu to the server... Do expect to see some lag until we determine just how many cores we'll need for a 20 player 128 tick server!

I just set the tick, I'm going in to check it out now

Originally Posted by Bunni

Exactly, you have to use VM's because windows is to clumsy to manage the memory of the virtualized processes itself (hearing how much you use vm's I doubt i need to explain how vm's work with memory) . Linux server up-times are expected to be months and frequently years, hardly warrant celebration like one would see for the same up-times on a windows server.

Actually we use VMs because we host entire networks and don't want to have racks upon racks of physical servers. And our VMs are run on windows server host boxes using MS failover clustering / hyperV. And we don't celebrate windows uptimes. We just point them out when linux fanatics point out how unstable windows is.

Ran pretty smooth though 40% cpu for one player and bots. Adding another cpu (will have 2 total), server will be down for 15-30 minutes or so.