API tools faq
paste
Advertisement
Guest User

To CS:GO Devs

a guest
Jun 14th, 2017
98
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 4.19 KB | None | 0 0
raw download clone embed print report
  1. Dear CS:GO developers, I would like to address an issue with dedicated servers. Currently, any servers running Linux suffers from a limitation. I've tried addressing this issue multiple times in the past but it still hasn't been fixed. From what I believe, CS:GO servers are suppose to use a separate thread for networking. However, I don't believe this is the case for CS:GO Linux servers at the moment.
  2.  
  3. I set up two servers (one Linux, one Windows) with the following settings:
  4. - 63 bots (bot_quota 63).
  5. - Bot_flipout 1 (if nonzero, bots use no CPU for AI. Instead, they run around randomly).
  6. - Sv_stressbots 1 (if set to 1, the server calculates data and fills packets to bots. Used for perf testing).
  7. - Running a map made for testing.
  8.  
  9. The Windows server had better performance than the Linux server. I've linked images of the CPU usage graphs below.
  10. Windows:
  11. http://g.gflclan.com/c750da34520d7b0f.png
  12.  
  13. Linux:
  14. http://g.gflclan.com/060564b1a69a5058.png
  15.  
  16. Both of these servers ran the same exact settings and as you can see, the Windows server could go above 100% CPU while the Linux server could not. With that said, I've hosted several live servers a couple years ago that filled up to 64 players each day. The same issue occurred on our CS:GO Linux server at 64 players and performance was terrible. As soon as we moved over to Windows, we saw a big improvement in performance and the server was using more than 100% CPU (basically another thread). This Linux limitation does not exist in any other Source Engine game as far as I am aware. I used to host a CS:S Linux server that reached 64 players each day and we easily went over 100% CPU while at high player counts.
  17.  
  18. After doing some testing, I've noticed a few things.
  19.  
  20. Occlusion_test_async Command
  21. "Enable asynchronous occlusion test in another thread; may save some server tick."
  22.  
  23. On Windows, this command has no effect and doesn't print any output.
  24.  
  25. On Linux, if set to 0, the server will stop using the (occlusion?) thread and performance is affected negatively.
  26.  
  27. As far as I am aware, the occlusion thread is used to help prevent wall hacks (please correct me if I'm wrong). I find it strange that this command has no effect on Windows servers but decreases performance on Linux servers when set to 0. The following is printed when the command is changed on Linux:
  28. Stopping 0 worker threads
  29. Starting 1 worker threads
  30. 1 threads. 1,014,658 ticks
  31.  
  32. Threadpool_cycle_reserve Command
  33. This command reserves any extra threads on the server. CS:GO Windows and Linux servers have different results with this command while running the same settings.
  34.  
  35. Windows:
  36. threadpool_cycle_reserve
  37. 2 threads being reserved
  38.  
  39. threadpool_cycle_reserve
  40. 0 threads being reserved
  41. While "occlusion_test_async" is set to 0.
  42.  
  43. --------------------------------------------
  44.  
  45. threadpool_cycle_reserve
  46. 2 threads being reserved
  47.  
  48. threadpool_cycle_reserve
  49. 0 threads being reserved
  50. While "occlusion_test_async" is set to 1.
  51.  
  52. Linux:
  53. threadpool_cycle_reserve
  54. 0 threads being reserved
  55.  
  56. threadpool_cycle_reserve
  57. 0 threads being reserved
  58. While "occlusion_test_async" is set to 0.
  59.  
  60. --------------------------------------------
  61.  
  62. threadpool_cycle_reserve
  63. 1 threads being reserved
  64.  
  65. threadpool_cycle_reserve
  66. 0 threads being reserved
  67. While "occlusion_test_async" is set to 1.
  68.  
  69. As you can see, there are extra threads running on Windows but not on Linux. The "occlusion_test_async" command has no effect on Windows while running "threadpool_cycle_reserve" but on Linux, it does have an effect.
  70.  
  71. I've also ran "threadpool_run_tests" on both servers and here are the results:
  72. Windows:
  73. https://pastebin.com/QiriPVTH
  74.  
  75. Linux:
  76. https://pastebin.com/DPWhHE7r
  77.  
  78. With that being said, I've tried the following to attempt to unlock the limitation on Linux:
  79. - Setting the "threads" command line option to 8.
  80. - Setting "host_thread_mode" to 0, 1, and 2.
  81. - Setting "threadpool_affinity" to 0 and 1.
  82. - Setting "net_queued_packet_thread" to 0 and 1.
  83. - Setting "sv_occlude_players" to 0 and 1.
  84.  
  85. None of these worked.
  86.  
  87. Overall, I've given all the information I can think of at the moment. If you need specific details, please let me know! I hope this issue is addressed in the near future!
  88.  
  89. Thank you for reading!
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!