NEWS Toronto Servers Back Up [Update]

liqvid

DARKLY Regular
Just to chime in. Might be something on my end, but I wanted to report it anyway.
I just played on the TO server for the first time since this downtime occured. It appears as though my ping has effectively doubled since then (was 80-120 and is now 170-210). At the same time, I noticed a constant fluctuation between 1 and 5% choke all round long for multiple rounds in a row (I didn't stay on the server very long. Was lagging way to hard). Before this downtime, and since the server was reinstalled a while back, Choke hasn't been an issue (0% constantly except during buy time). The fact that it is back now concerns me.

Again, note: I only played around 5 rounds and during that time the server had around 28 players on it. Map was office.
 

Shotgun Jesus

TD Admin
Staff member
Just to chime in. Might be something on my end, but I wanted to report it anyway.
I just played on the TO server for the first time since this downtime occured. It appears as though my ping has effectively doubled since then (was 80-120 and is now 170-210). At the same time, I noticed a constant fluctuation between 1 and 5% choke all round long for multiple rounds in a row (I didn't stay on the server very long. Was lagging way to hard). Before this downtime, and since the server was reinstalled a while back, Choke hasn't been an issue (0% constantly except during buy time). The fact that it is back now concerns me.

Again, note: I only played around 5 rounds and during that time the server had around 28 players on it. Map was office.

Out of curiosity, what's your ping on: 74.91.113.242:27015 ?
 

Shotgun Jesus

TD Admin
Staff member
Fucking lag!
Time to move to Chicago.

pakikid.jpg
 

up-n-atom

DARKLY Regular
Don't know where to suggest this but since this thread is the most recent regarding server performance I'm gonna post it here.

I've been doing some reading on server setup/maintenance/performance and if you've tried to use some of recently added convars? There is an interesting 1 that is being used to mitigate CPU usage and bandwidth: sv_force_transmit_players 0 - It's apparent purpose is to enable/disable calculating and sending player info if they're out of the field of view. e.g. players guarding and rushing bomb-site B world view (3D) info is being sent to those in bomb-site A. By default it is on and that seems like a big waste of resources.
 
Last edited:

Shotgun Jesus

TD Admin
Staff member
Don't know where to suggest this but since this thread is the most recent regarding server performance I'm gonna post it here.

I've been doing some reading on server setup/maintenance/performance and if you've tried to use some of recently added convars? There is an interesting 1 that is being used to mitigate CPU usage and bandwidth: sv_force_transmit_players 0 - It's purpose is to disable calculating and sending player info even if they're out of the field of view. e.g. players guarding and rushing bomb-site B world view (3D) info is being sent to those in bomb-site A. By default it is on and that seems like a big waste of resources because the client won't render it.
I've set it to '0' now.

And still lag. Fuck.
 
Last edited:

up-n-atom

DARKLY Regular
You'll probably know this but maybe something was missed and it's a long shot these might fix the spikes. Some settings related to Linux that are important to a finely tuned server that you may want to verify...

High resolution timers (HPET): Check to see if it's available, in use, and set. Here's a how-to https://access.redhat.com/documenta...ime_Tuning_Guide-Timestamping-Hardware_Clocks. That's not persistent between reboots but you can add "clocksource=hpet" to your kernel command line arguments. This is discussed in https://list.valvesoftware.com/pipermail/csgo_servers/2014-July/009136.html due to the removal of convar sleep_when_meeting_framerate_headroom_ms.

CPU Scaling: Check that it's not set for power save. It should be either on-demand or performance. It's self explanatory but here's the differences https://access.redhat.com/documenta...Power_Management_Guide/cpufreq_governors.html. Change the governor using either cpupower or the legacy cpufrequtil. https://access.redhat.com/documenta...tml/Power_Management_Guide/cpufreq_setup.html (RedHat) and https://wiki.debian.org/HowTo/CpuFrequencyScaling (Debian). The less proper way is to list the governors by running "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" replacing cpu0 with cpu1, cpu2, cpu3, etc. for each core. And to set it by running "echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" or "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor".
 

Low Budget

DGN Staff
Staff member
The host is going to try a few more things but if we can't find the root of the problem, the only solution is to move all our Toronto servers to Chicago and host them with NFO.

Higher ping vs. Lag - what would you rather have?

Sent from my Q10 using Tapatalk 2
 

everyth1ng

DARKLY Regular
Couldn't you guys just try another provider in Toronto?

I'm fine with moving the servers to Chicago, like I said in one of the other threads. 15-15 ping is still very acceptable.
 

up-n-atom

DARKLY Regular
such nerd talk, dont understand. More pew pew needed

The server should be no different than what you typically enable as a client. In BIOS you should have HPET enabled and for Windows 7 and prior you can then enable it via command prompt with "
bcdedit /set useplatformclock true" (disable run "bcdedit /deletevalue useplatformclock") and it's used by default in Windows 8. You should also be running with the "High Performance" power plan via Control Panel > System and Security > Power Options. On the server the problem can be that you might have enabled such features but not in a persistent manor ie. via terminal and echoing to sysfs and the settings are lost between reboots. I've brought it up as a refresher and it's good reference even if it's a little geeky.
 

Low Budget

DGN Staff
Staff member
The funny thing is, the server was running great for the longest time. And sometime around a year ago, the lag problem started. Mind you we made no changes to anything on the box prior to the lag starting. Initially we blamed valve for the lag, the box itself has no problem, never did. It can only be a problem with the host at the DC. But they are telling us that no other clients are complaining about lag, and that it's just us. But our server itself is fine. So, what is the root of the problem? :shrug:
All I know is that on a cheap VPS with NFO, our chicago comp server runs better than on our powerful dedicated Toronto server. :yaoming:
 
Top