NEWS Toronto Servers Back Up [Update]

[Low Budget]

Have you guys thought of trying Quebec?

The problem is finding a host that has good routing and decent ping for everyone. Sure quebec may work great for us Canadian but it may not for our US players. And it's a pain in the ass looking for providers, asking for test IP and getting everyone to ping and traceroute and post on forum. And what happens if we switch to a host and they are pure AIDS. There is a lot of work involved in transferring everything over, not to mention potentially losing a lot of regulars due to IP change.
So we have to make sure it's a reliable and good host before we commit to anything. Chicago is one of the biggest hubs in NA, so ping will be good for everyone in general. And we have a lot of experience with NFO and know they have solid and reliable servers. So I wouldn't think twice to move servers there if we had to.

Again we don't want to be jumping from host to host until we find one that fits us. This is how we will kill this community. Let's get it right and make only one move if we have to. We've had to switch hosts plenty of times in our history, and it's never been a fun process.

 

[Gatherix]

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".

I hadn't thought of changing the clocksource, mainly because some statistical network data we collected pointed pretty clearly to the host's network, though given the nature of the problem we don't really know whether those supposed network issues are related to the lag spikes. HPET is available, so I suppose we could give that a go?

Seeing as you prolly know more than I do, some clarification would be nice. Right now the clocksource is TSC; as far as I understand it, the time stamp counter ticks every clock cycle, but that leaves the possibility of the counter being out of sync if the clock speed changes to save power. right? As for HPET, I don't know much beyond what it actually is; I've heard and experienced mixed results, client-side and server-side. Assuming it's set to be used in both the BIOS and the OS, and that the OS is forced to use it instead of alternatives, what is the actual technical impact? I haven't really seen any tangible, consistent explanation besides just benchmarks and chance, but I can't imagine it's just statistical.

CPU scaling is already set to on demand, checked that awhile ago.

 

[everyth1ng]

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?
All I know is that on a cheap VPS with NFO, our chicago comp server runs better than on our powerful dedicated Toronto server.

I remember very clearly that these problems coincided with my increased ping. Up until about July or so of 2013, my ping was below 15 at all times. This was with Bell. And then I started having routing problems that only continued to worsen as time went on.

 

[Low Budget]

Another thing to note is the server load is perfectly fine when the lag is experienced on the servers. We have monitored it many times. CPU and server load remain the same while everyone lags like a mofo.

 

[amanshotme]

dat charcoal yao ming...priceless

 

[up-n-atom]

I hadn't thought of changing the clocksource, mainly because some statistical network data we collected pointed pretty clearly to the host's network, though given the nature of the problem we don't really know whether those supposed network issues are related to the lag spikes. HPET is available, so I suppose we could give that a go?

Seeing as you prolly know more than I do, some clarification would be nice. Right now the clocksource is TSC; as far as I understand it, the time stamp counter ticks every clock cycle, but that leaves the possibility of the counter being out of sync if the clock speed changes to save power. right? As for HPET, I don't know much beyond what it actually is; I've heard and experienced mixed results, client-side and server-side. Assuming it's set to be used in both the BIOS and the OS, and that the OS is forced to use it instead of alternatives, what is the actual technical impact? I haven't really seen any tangible, consistent explanation besides just benchmarks and chance, but I can't imagine it's just statistical.

CPU scaling is already set to on demand, checked that awhile ago.

It's essential in the use of a tickless kernel http://www.landley.net/kdocs/ols/2007/ols2007v2-pages-201-208.pdf which is where Linux is today but I'm inclined to believe that most srcds servers are recompiled as preemptive or realtime. I'm just bringing atttention to tidbits found on the cs:go server mailing list and fixes to dropped convars if they may relate https://list.valvesoftware.com/pipermail/csgo_servers/2014-July/009136.html. It's minor enough to try.

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?
All I know is that on a cheap VPS with NFO, our chicago comp server runs better than on our powerful dedicated Toronto server.

About a year ago the networking model was changed to be threaded.

http://blog.counter-strike.net/index.php/2014/02/9578/

"Added support for threaded socket processing on clients and servers."

And a few months later they added convars for such

http://blog.counter-strike.net/index.php/2014/05/9620/

"Added support for per-channel ratelimits in engine threaded network layer, ratelimits are controlled with a group of net_threaded_socket convars."

net_threaded_socket_burst_cap 256 // Max number of packets per burst beyond which threaded socket pump algorithm will start dropping packets.
net_threaded_socket_recovery_rate 6400 // Number of packets per second that threaded socket pump algorithm allows from client.
net_threaded_socket_recovery_time 60 // Number of seconds over which the threaded socket pump algorithm will fully recover client ratelimit.

The 1st may be a cause for intermittent lag. I found little information on tuning those variables.

 

[Gatherix]

About a year ago the networking model was changed to be threaded.

http://blog.counter-strike.net/index.php/2014/02/9578/

"Added support for threaded socket processing on clients and servers."

And a few months later they added convars for such

http://blog.counter-strike.net/index.php/2014/05/9620/

"Added support for per-channel ratelimits in engine threaded network layer, ratelimits are controlled with a group of net_threaded_socket convars."

net_threaded_socket_burst_cap 256 // Max number of packets per burst beyond which threaded socket pump algorithm will start dropping packets.
net_threaded_socket_recovery_rate 6400 // Number of packets per second that threaded socket pump algorithm allows from client.
net_threaded_socket_recovery_time 60 // Number of seconds over which the threaded socket pump algorithm will fully recover client ratelimit.

The 1st may be a cause for intermittent lag.

The TF2 servers experience a similar lag as the CS servers, and do not have the said network model. We're not 100% positive the two lags experienced are the same, but it's a pretty safe assumption, given the testing we've done.

 

[up-n-atom]

The TF2 servers experience a similar lag as the CS servers, and do not have the said network model. We're not 100% positive the two lags experienced are the same, but it's a pretty safe assumption, given the testing we've done.

The TF2 srcds different from that of CS:GO? I'd assumed they were the same... Not gonna argue your tests and I'm also inclined to believe it's caused by the provider. Just keep on hounding them :P

 

[Steve]

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.

Have you guys thought of trying Quebec?

tf2 has a strong american populations. Quebec servers = aids ping for most of america

also fuck yo shit, I played on TD FOR YEARS with a greater than 100 ping.

Some people just be bitchin about reg and ping in a pub, others be chilling having a laugh and beer and enjoying there time in that same pub.

 

[Steve]

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?
All I know is that on a cheap VPS with NFO, our chicago comp server runs better than on our powerful dedicated Toronto server.

DARKLY Powered by 'MURICA coming in 2015...

 

[shoottomaim]

At least the steam shit works fine now

 

[up-n-atom]

2 hours and 4 maps in not a single major spike albeit a lot of 100+ pings but that ain't got nothing to do with the server.

 

[Low Budget]

2 hours and 4 maps in not a single major spike albeit a lot of 100+ pings but that ain't got nothing to do with the server.

See sometimes it doesn't happen for a while, and other times it happens a lot. So it's the derpy network.

Sent from my Q10 using Tapatalk 2

 

[shoottomaim]

See sometimes it doesn't happen for a while, and other times it happens a lot. So it's the derpy network.

Sent from my Q10 using Tapatalk 2

Why can't the host just change ISPs?

 

[Gatherix]

Why can't the host just change ISPs?

The servers are in a datacenter, not a basement.

 

[Cmp™]

I'm in the NorthWest part of the US and regularly have 80+ ping and I still manage to be decent. But I also remember the fact that I'm in a trade server and if I'm really bitching about how ping is affecting my game (unless it's outrageous), I'm trying too hard.

This is a chill community and we're here to have fun and play. I don't play CS, so I'm not as familiar with the nature of how ping affects that, but I would think that at the end of the day, it shouldn't matter who's on top, as long as you had fun. I used to hop on and join in on CS for the hell of it when Rams sent me an invite. It was fun as hell, even though I got my ass handed to me every single time.

TL;DR: I regularly have 80+ ping and it's all good over here.

 

[Low Budget]

Why can't the host just change ISPs?

Sent from my Q10 using Tapatalk 2

 

[Shotgun Jesus]

Shoot, do you even Asian bro?

 

[everyth1ng]

also fuck yo shit, I played on TD FOR YEARS with a greater than 100 ping.

Some people just be bitchin about reg and ping in a pub, others be chilling having a laugh and beer and enjoying there time in that same pub.

@Steve , I'm well aware of what playing on TD feels like with 60-200 ping for an extended period of time. It's not good for anything, casual play or otherwise. The way you're framing your argument is coming across to me as a false dilemma. And the rules of the server don't discourage against trying. Any type of strategy that doesn't involve rushing into a room without checking corners is considered 'camping' to you. Any type of behaviour that doesn't involve baby sitting every single teammate in your vicinity when they go and do stupid shit is considered 'baiting' to you. There's probably nothing that I can say to persuade you about anything. That's fine. But you're wrong, at least about some things.

 

[Steve]

@Steve a bunch of stuff

Only called you out on baiting monster in a 2v1 against me, calm down son.

atleast you do objectives,

you have to realize we are a pub server at the end of the day and have people connecting from all across north MURICA and zackyland. people are going to have higher pings. Nothing outrageous but people were crying about 150 pings.


at the end of the day all this lag is Toronto's fault. For the first time in 9 years we might have to host out side of toronto??? RIP