When sv_maxrate is set to w/e reasonable, for sake of the convo lets say its 60000, and the client has a large value set like: rate 1000000 network packets get very small ~64 byte etc, which makes that the server is pumping out mainly packets, but not much data. Unfortunately, that influences the other players as well.
I agree that the rate setting will limit the data transfer, and with any normal values it will work. I have no idea why OB servers gets influenced so much by it. I just observe that it is so. On the +66 settings, it also does influence. Unfortunately valve has not heard of sanitizing input to variables on the client. The + values are used for a number of things by players: - avoiding ping kicks, for the ping calculation goes wrong - arbitrarely adjust rate settings. The + sign is somehow interpreted badly by the game engine and results in a negative effect. and "but a + sign should be valid if the parser is smart" ... I lolled. The server rate settings work if the rates on the client are set "normal", without the high rate 1M setting or the + values. If such players are on your server, the rate value needs to be higher and the server performance is less. And I'm really not telling anything new. and anyways, for clients I advise: // full, good connection rate 50000 cl_cmdrate 67 cl_updaterate 67 cl_interp 0.034 cl_interp_ratio 2.0 // half, mediocre rate 30000 cl_cmdrate 33 cl_updaterate 33 cl_interp 0.064 cl_interp_ratio 2.0 // default, but better rate: rate 25000 cl_cmdrate 30 cl_updaterate 20 cl_interp 0.100 cl_interp_ratio 2.0 default rate are 3500, 5000, 7500 and 10000, depending on the internet connection setting in steam client. >________________________________ > From: hlds <[email protected]> >To: 'Mart-Jan Reeuwijk' <[email protected]>; 'Half-Life dedicated Linux >server mailing list' <[email protected]> >Sent: Sunday, 8 April 2012, 15:37 >Subject: RE: [hlds_linux] Poor TF2 performance on a dedicated server > >The rate is used to compute the time when the next update can be sent to a >client. A a huge value means that the updates can be sent almost anytime. >But the server won't send more than min(66, sv_maxupdaterate) updates to a >client because it has only 66 frames per second, so a player can use >9999999999999999999 for rate without problems (is something like: >nextUpdateTime = currentTime + 0). Anyway you can limit the maximum value >using sv_maxrate, so there's no need to kick players for this. > >Also the values for convars are retrieved as an int or as a double. If the >convar has an invalid value (+50 or X50 or XyZ or whatever) then the result >is 0 (but a + sign should be valid if the parser is smart, same like - is >valid for negative values). Kicking players for this is silly when you can >enforce the limits using sv_minrate, sv_maxrate, sv_mincmdrate, >sv_maxcmdrate, sv_minupdaterate and sv_maxupdaterate. > >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf Of Mart-Jan >Reeuwijk >Sent: Sunday, April 08, 2012 4:08 PM >To: Half-Life dedicated Linux server mailing list >Subject: Re: [hlds_linux] Poor TF2 performance on a dedicated 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) >... > > > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
