-- [ Picked text/plain from multipart/alternative ] The maximum sv_maxrate of 30000 was told to me directly by Alfred that it is currently hard coded into SRCDS, so that is where I get my authority on that subject. Ask Alfred off list for confirmation if you want. Who knows, maybe this value will change.
On a side note, I do remember the Valve Developer Site notes for SRCDS once saying it could support up to 255 players or some fancilful number like that, but this has now disappeared. Maybe there are others out there who can testify to witnessing the same value for the supposed original online multiplayer limit that was envisaged for SRCDS? You are correct, about cl_rate (which no longer exists anyway) and I should change it, and yes, the clients can easily send more than 10KBytes/Second worth of data. cl_updaterate has a hard limit of 100 (from memory), cl_cmdrate does not seem to have a hard limit other than the clients fps, but due to the nature of SRCDS client/server communications, all you end up doing is sending the same amount of data after a certain point no matter how high the cl_cmdrate is. I have been at Valve to provide a SRCDS Netcode explanation on how things should be setup in optimal circumstances, rather than the 20/30/56Kbitsps with 33% packet loss explanation they currently have. BTW, its a wiki, create an account and fix it yourself :p On 4/27/06, James Tucker <[EMAIL PROTECTED]> wrote: > > Whisper, sorry dude, as I know you've been working on this > documentation for a long time (and I've been away for a while) > however, where on earth do you get the "maximum" values for rate and > sv_maxrate? > > Those maximums don't exist. If I set sv_maxrate 10000000 and rate > 10000000 then I can get maps down from a server on the local lan MUCH > faster than sv_maxrate 30000. > > Another thing, you still have suggestions of cl_cmdrate 101; cl_rate > 10000, now I know this is a deprecated cvar, however it's the notion > that upsets me significantly. cl_cmdrate 101 does not fit into 10kBps. > I don't use net_graph as it is too coarse generally, but you will see > even on net_graph that in certain instances (particularly player > deaths, high physics interactions (very much moreso with hl2dm), level > resets, cs:s bomb explosions) 10kBps is not enough bandwidth to > transfer all of the state changes from the client to the server, or > visa versa. > > In fact, in recent tests, the same is true of server to client data > transfers. Try configuring a server with sv_maxrate 0, > sv_maxupdaterate 100 and a client with rate 1000000 and cl_updaterate > 100. Populate the server with bots / players and then view the > bandwidth usage on the graph or in net_channels. Also check the server > stats for total bandwidth transferred. It is not uncommon that the > server needs to transfer higher bandwidths than 30kBps, again moreso > for hl2dm than cs:s, however true for both. > > In future implementations of the source engine (as the gameworlds > become more movable) we will see more and more bandwidth being used, > so we need to get vigilant of these things sooner rather than later. > > The lag that you see with sv_maxrate 0 is the oddity of unrestricting > the connection and reaching MTU / bandwidth boundaries on the server, > as you would see in other flows like VOIP apps etc. As you know, > sv_maxrate, MR, should be the servers total outgoing bandwidth B, > divided by the number of players N for ideal performance, leading you > to: > > MR = B / N > > for a 10mbps server with 64 subscribers, this would be roughly: > > n.b. B = 10mbps / 8 to get mBps. > > MR = (10 000 000 / 8) / 64 > MR = 19 531 > > Obviously this is quite an extreme case, in a way. Many commercial > deployments having about 5-10mbps available, and running about 60 > players throught them (2 or 3 instances of SRCDS per box). In this > case, you can see where these bandwidth caps really can defend against > loss if they are set correctly. > > Finally, going back to the sv_maxrate maximum value issue, if the > maximum value was 30000, then leaving sv_maxrate 0 is equivalent to > sv_maxrate 30000. This however is clearly NOT the case, as you > yourself state in the documentation. It is also important to note that > cl_updaterate is documented in the engine itself to have a maximal > value, and no such maximal values are ever stated for the 'rate' > variables. > > > Hope all is well over in your kneck of the woods, I've been run off my > feet with Red Orchestra, BF 2, Quake 4 etc aswell as a bunch of other > bespoke projects. > > Keep up the good work, > > James. > > On 25/04/06, Whisper <[EMAIL PROTECTED]> wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > Here you go Alexander > > > > http://whisper.ausgamers.com/wiki/index.php/Tickrate > > > > It is for SRCDS only though > > > > On 4/25/06, Alexander Kobbevik <[EMAIL PROTECTED]> wrote: > > > > > > If by accident there is any information in this thread that can be > > > useful for an admin, can someone make a summary for me please? > > > > > > Thanks :) > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Roman Hatsiev > > > Sent: 25. april 2006 10:12 > > > To: hlds@list.valvesoftware.com > > > Subject: Re: [hlds] SRCDS will not run > > > > > > At least we have someone to blame. But please be careful next time, > pal > > > :) > > > > > > On 25/04/06, Whisper <[EMAIL PROTECTED]> wrote: > > > > -- > > > > [ Picked text/plain from multipart/alternative ] > > > > I'm sorry, it's my fault > > > > > > > > I've created a monster > > > > > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > -- > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
