Thats why I solve that crap from the server: // setting min and max rate's (bytes per second TO the client) sv_maxrate 60000 sv_minrate 30000
// setting min and max updaterate (number of updates per second TO the client) sv_maxupdaterate 67 sv_minupdaterate 33 // setting min and max cmdrate (number of updates per second FROM the client) sv_maxcmdrate 67 sv_mincmdrate 33 // setting limits for the interpolation on the client, x = over x updates there can be interpolation sv_client_max_interp_ratio 2 sv_client_min_interp_ratio 1 // personally have the min_interp on 2 as well. // set cl_predict on connected clients to 1 (only while connected) sv_client_predict 1 Reason for mincmdrate and minupdaterate to be 33 is that its exactly half the tickrate, most people play on defaults (updaterate 20, cmdrate 30) so that lifts them to half the tickrate of the server, which makes their experience better, and easier for the server. And put a plugin in that kicks players for: - client rate value over 100000 (over 100 k will make the packets from your server shorter and shorter up to a point where the packet data vs the content is bigger, yes even if you have sv_maxrate set) - rate values with a + in front (rate +50000, cl_cmdrate +66, cl_updaterate +66 etc) - ping over 150 ms Yeah, I know, the settings are not friendly for dial up, but last time I was around any dial up is a long time ago, and I dont know anybody still using dial up. Pretty sure that that dinosaur is extinct in my country. And anyways, with dial up the connection is bad anyway for gaming. >________________________________ > From: Jesse Molina <[email protected]> >To: Mart-Jan Reeuwijk <[email protected]>; Half-Life dedicated Linux server >mailing list <[email protected]> >Sent: Sunday, 8 April 2012, 14:46 >Subject: Re: [hlds_linux] Poor TF2 performance on a dedicated server > > >Correct. But, the real problem is that users are being honest at some >point and their honesty is causing them pain. > >You live in Denver, have 256K ADSL back in 2006, then you move to >Chicago and have 50/20M cable in 2010, but you're settings are still >from 2005 when you had 256K ADSL and the result is that you are punished >with crappy game performance. > >Average users don't mess with autoexec.cfg or the rate commands. > >But yea, feel free to just use the commands like he said below. > >Good discussion. > > > >Mart-Jan Reeuwijk wrote: >> [quote] >>> Be sure that your client is configured like this, no matter what your >> real network connection is (That is, set it to 10M/max). I've had lots >> of users complain of lag and this fixed it> for them; >>> >>> http://whisper.ausgamers.com/wiki/index.php/Bad_choke_solution >> [/quote] >> >> >> The only thing that that does is setting the rate to 10.000 >> >> HKEY_CURRENT_USER\Software\Valve\Steam >> value: rate >> >> rate 10000 >> can be set in the console or in autoexec.cfg as well. Altho my experience is >> that on TF2 a rate of 10000 is too low, I'd advice a minimum of 20000 or >> 25000 >> >> >> >> >>> ________________________________ >>> From: Jesse Molina<[email protected]> >>> To: Half-Life dedicated Linux server mailing >>> list<[email protected]> >>> Sent: Sunday, 8 April 2012, 4:09 >>> Subject: Re: [hlds_linux] Poor TF2 performance on a dedicated server >>> >>> >>> I don't know about your particular situation, but for the money you paid >>> for this "server class" CPU and the motherboard, you could have gotten much >>> better performance out of a desktop CPU and board. You probably should >>> have gone with a CPU with fewer cores but a higher clock frequency. >>> >>> There are very few tools in the srcds process itself that will help you >>> troubleshoot issues outside of memory exhaustion and configuration >>> problems, so don't look there. >>> >>> You need to be using "net_graph 5" on the client. What is your app ping >>> like? When you get over 80ms, you will start to see a choke effect that is >>> very similar to TCP window exhaustion. It seems to be built into the >>> server, where if it does not get client feedback in time, it will choke off >>> future updates. As far as I know, there is nothing that can be done about >>> this. >>> >>> Do yourself a favor and do this; >>> >>> >>> >>> On my Windows 7 system, the path of my TF2 cfg directory is this; >>> C:\Program Files (x86)\Steam\SteamApps\<username>\team fortress 2\tf\cfg >>> >>> In this directory, create or edit the file named "autoexec.cfg" >>> >>> Put the following into the file; >>> >>> Code: >>> //netgraph script >>> alias graph "graph1" >>> alias graph1 "net_graphpos 1 ; net_graphproportionalfont 0 ; net_graph 4 ; >>> alias graph graph2" >>> alias graph2 "net_graphpos 1 ; net_graphproportionalfont 1 ; net_graph 4 ; >>> alias graph graph3" >>> alias graph3 "net_graphpos 1 ; net_graphproportionalfont 0 ; net_graph 1 ; >>> alias graph graph4" >>> alias graph4 "net_graphpos 1 ; net_graphproportionalfont 1 ; net_graph 1 ; >>> alias graph graph5" >>> alias graph5 "net_graphpos 1 ; net_graph 0 ; alias graph graph1" >>> bind "p" "graph" >>> >>> This script makes it so that when you press "p" on your keyboard, it cycles >>> through the net_graph in four different styles; >>> >>> graph plus large-text stats >>> graph plus small-text stats >>> large-text stats with no graph >>> small-text stats with no graph >>> >>> On the netgraph, pay attention to the choke, sv, loss, and var values. When >>> sv dips, your CPU is probably pegged out. Choke is the server holding back >>> packets. Loss is obvious. Var is basically jitter. >>> >>> >>> >>> Be sure that your client is configured like this, no matter what your real >>> network connection is (That is, set it to 10M/max). I've had lots of users >>> complain of lag and this fixed it for them; >>> >>> http://whisper.ausgamers.com/wiki/index.php/Bad_choke_solution >>> >>> >>> >>> You will see a lot of bad advice out there about compiling your kernel, >>> realtime, and other garbage. THere are a lot of very eager-to-please noob >>> kids who want to run servers, but they don't know squat about being a >>> sysadmin. >>> >>> You are running a very modern kernel on amd64; that's good. >>> >>> Could be some BIOS thing. Set it to defaults and don't fark with it unless >>> you know what you are doing. >>> >>> >>> >>> Go back to the first thing I wrote on this email, and kick yourself for >>> wasting money AND getting slower hardware than you could have had. Those >>> Opterons are good for "wide" multi-threaded multi-user type applications, >>> but that isn't what srcds is. >>> >>> >>> >>> Good luck >>> >>> >>> frog wrote: >>>> >>>> We've got dedicated server, 6 x 2.3ghz (AMD Opteron 6276), 16GB RAM, 200GB >>>> HDD, which struggles to run a full 24 slot TF2 server smoothly. >>> >>> -- # Jesse Molina >>> # Mail = [email protected] >>> # Page = [email protected] >>> # Cell = 1.602.323.7608 >>> # Web = http://www.opendreams.net/jesse/ >>> >>> >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >>> >>> >>> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > >-- ># Jesse Molina ># Mail = [email protected] ># Page = [email protected] ># Cell = 1.602.323.7608 ># Web = http://www.opendreams.net/jesse/ > > > > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
