If you are a member of our Steam group, then you probably have already seen the announcement and “event” that I posted last week. In short, you know that I am attempting to set up another server for our loyal members… this time for Synergy Coop.
It’s also likely that you know I set the event date for 6:00 am CST tomorrow. At the time, I was anticipating trouble getting the server ready with add-ons. Regretably, I didn’t make it that far.
On the 15th of March, in the early morning hours locally, I ordered a 10-slot Synergy server. I plan to make it public except for periods of recording a gameplay show I have planned.
The only problem was that once I joined the server, it began lagging terribly. At times, the screen appears to jump back and forth between two positions. At others, it appears to stutter. And on rare occassion it appears to loose the connection and regain it.
Okay, my first thought was that maybe I had something messed up on my end. I eventually went so far as to remove and re-install Synergy on my own machine. But the problems continue.
Then I decided to get Syrus on the server to test it and he experienced the same lag problem. As did a few random people that joined. They joined because our server’s ping was in the 30’s or 40’s at it’s worst… at least locally.
It seems to be a good connection with my own ping fluctuating between 47 and 107. But the lag is present in all things server side.
So I had basically determined that the problem was server side. I tried several more tricks to be certain and even waited a day to make sure that the problem wouldn’t resolve itself.
Then I gave in and filed a support ticket. I explained the situation and that the game was basically unplayable. I noted that the lag issue doesn’t seem present until NPC’s spawn.
A support technician responded to let me know they work checking the issue and when they were ready for me to try the server again. Unfortunately, I had to go to work that night and found myself stuck with an extra 4.5 hour holdover in the morning.
I do hate holdovers.
When I returned, I tried the server once again and found the problem unresolved. I reported this and noted the NPC’s once again. At times, it even seems to help to move away from them.
I was then asked if I had installed any add-ons. The answer of course was no. I haven’t had a working server to install anything on yet.
The technician asked if I wanted to try re-installing the server and said that he wasn’t sure what the problem could be. I agreed to the re-install and once again tested the new server.
Yet, the lag remained. I looked at my configuration files and noted sv_maxrate 66, but wrote that off as part of the variables governing my 66 tickrate.
I could see no issue and the tech support folks [there have been three or four now by the way] suggested deleting the current server and installing on a different machine. I agreed and tested once again.
Still the server lagged painfully. Words cannot describe how bitterly bad this lag really is. The game is completely unplayable.
By this point, I and Syrus both had been scouring google and bing for answers. But no one seems to have had this particular problem. We considered this strange, but I continued to search.
Gradually, I made my way around to the variables I had noted earlier. Particularly that sv_maxrate 66. Something about that setting just felt wrong. And the more I searched, the more I found new equations for calculating sv_maxrate and setting it in the thousands.
And then I found an article about “Setting up a Standalone Dedicated Server” on support.steampowered.com. And it mentions sv_maxrate set to 1000 as a minimum and the default being 10000. The article defines sv_maxrate as “…the maximum rate of bytes per second which the server is allowed to transmit…”
Wow… wait a moment. Bytes per second?
As in, the cfg file is trying to set the server’s transmissions at a rate of 66 bytes per second?
Oh my…
Yes, it would appear that this number is my culpret. The actual settings were sv_maxrate 66 and sv_maxupdaterate 66.
I asked a question, but not before the tech support folks had started moving my server to the Chicago location to try to fix my lag problem. The response was that sv_maxrate can not be more then 66 on a 66 tickrate server.
Now, I’ll admit, I’ve been playing dumb with these guys. As I explained to Syrus, I don’t really want these folks to know that I actually know a little something about computers and networking. Networking, in particular, was not my strongest class at University [mainly because the professor was boring and read all his lectures off power point presentations *shudders*].
And I am a bit rusty in many of my subjects. Honestly, I don’t want these tech help types assuming that I know anything… because then important steps get skipped. And I also want to know if they try to lie to me about anything for any reason… particularly to scam extra dollars out of me.
Bottom line, I want them to think I’m just some dumb kid that doesn’t know anything.
Nonetheless, I actually do know that 66 bytes per second is abysmal and the general consensus on all gaming forums is that sv_maxrate should be in the thousands.
10000 > 66
But according to tech help, 66 was the right setting. The transfer to the Chicago location completed while we dealt with a power outage here thanks to thunderstorms. [seriously, I’m telling you this has been a long mess with many curveballs thrown at me.]
Once I was back on-line, I tested the new server and the lag was *gasp* still present.
I have since reported this and pointed out two very important facts regarding the sv_maxrate variable. It is important to note that the server has been on-line and unplayable for the four days already.
First, I again politely asked about the sv_maxrate setting… though I must admit I typed sv_maxupdate in the first sentence. [oops] I took a moment to re-iterate the steampowered.com definition of sv_maxrate as bytes per second. Noting that 66 bytes per second is pretty bad, I also pointed out that 1000 was the stated minimum by that article.
Second, I pointed out a different web page. During my searching I stumbled onto a page on counter-strike.com. This is important because the first two iterations of this server had counter-strike.com server addresses as it is apparently a part of the LowPings family.
On the page mentioned, which is dedicated to tickrates on the Counter-Strike servers, they state that a 66 tickrate server should have sv_maxupdaterate set to 66 and sv_maxrate set to 20000.
Wait… what?
Tech support said sv_maxrate couldn’t go above 66. The page I referenced here is on THEIR BLOODY SITE. WHAT THE HELL!?
20000 > 66
So yes, I pointed this out politely and asked if Synergy is different somehow… because you never know. But I already know the answer. The CORRECT answer that is.
They set up the server wrong and didn’t think to check the server.cfg file and left it to me to figure out my own problem.
I’m at this moment waiting for their answer, and am still trying to play dumb for their support ticket. However, I DO already know the answer and am only waiting for the response before I fix the problem myself.
While I was in game the last time, I took a screenshot of the net_graph and attached that too. Check out the choke of 189.
An effect that I had previously described to them as feeling like a bottleneck. Now I know why.
Source Dedicated Servers override clients when it comes to transmission of data. The server is trying to send data packets [66 packets per second] at a rate of 66 bytes of data per second.
Something about the math here doesn’t add up.
I don’t dislike LowPings or their tech support folks. In fact, I believe the issue here is one of reading my messages too quickly and being to busy with other people’s support tickets, and not checking the most simple points first.
When you are debugging a PC hardware problem, the first step is to check all the cables and connections. This is a basic principle, yet we with a bit of experience under our belt often forget ourselves and skip that step.
Thus, the solution is often the last place we would think to look and the first place that we SHOULD have looked. In the case of this server problem, the server.cfg file should have been the first place we all looked.
I don’t blame these folks for missing this point as I obviously missed it myself. But think of all the wasted man-hours and bandwidth now. Four days of server issues. This server has been re-installed, deleted, installed on a new machine, and transferred from one data center to another. With no effect… because the cfg file is still limiting the server to sending only 66 bytes of data per second.
And then one of them tells me that 66 is the correct setting when their own website says 20000 is the correct setting. It just saddens me a bit. And frustrates me.
All in all it just goes to show you that I am epically awesome in every way and can solve problems that tech support cannot.
Kneel before The Wildcat and his mad server skills!
=P
// did I mention I sent my last query at 1:59 am and it is now 3:12 am without a response.
