On 7/18/05, Vapor <[EMAIL PROTECTED]> wrote: > Servers I manage operate on 1 or 2 x 100mbit full duplex connections per box, > which run from 3-6 clan ports or publics, say 30-120 slots. Based on this > server side bandwidth is never an issue, bearing in mind the maxrates of these > servers is 50000 kbits. In fact our clients in general don't even consider the > bandwidth they use as we impose no limitation. So auto-rates serve no purpose > here.
Equally however, setting your maxrate's correctly won't cause your servers a problem and will provide maximum capabilities for map downloads. Assuming most clients accept the map, all you've done is save time, and if you are on a scheme of bandwidth measures in percentiles, it probably saves you some cash too. > Client side connections to our game servers are primarily from broadband > clients using ADSL or cable (512kbps/256kbps being the average), very few ISDN > users (64kbps) and hardly any analogue modemers. Clients connections although > contended do not suffer the severe bandwidth losses you have highlighted (love > the examples btw :D), the majority seeing solid sustained average rates at all > times. So again auto-rates serve no purpose here. Again, I would disagree, a 256k line can handle significantly higher rates than the defaults, providing more accurate gameplay. Why not provide everyone with advantage? rather than client needing to know about rates. > I can see however that should we provide a volume of community servers, free > of charge to the public, in a region where clients did suffer such a varying > level of bandwidth, your ideas would be welcomed. However, we primarily > provide performance (high tick/fps) private match servers to clans on a rental > basis. Our emphasis is on the performance of the server and to that end clans > are looking for the maximum bang (tick/fps/good bullet reg) for their buck > with as much control over the configuration as allowable. As you can see this > differs massively from the criteria desired of a community public. Yes indeed, although even stable connections can be imperfect, some dynamic compensation is always welcomed if you want maximum accuracy. > All of the above not withstanding I feel there is a much bigger issue > responsible for not using an auto-rate system, server side overheads. CS and > CSS servers already consume considerable resources using a fixed rate system, > I can only see an auto-rate system increasing this resource usage, nevermind > the recoding of whatever server and client side to add this feature. Given the real importance of granular changes in rate (not very much at all) a trickle set system would not increase load significantly as it should not have to record very much, nor should it have to run very frequently. > To instigate an auto system to outright replace the existing options would > however be a total disaster in the UK and Europe. In our region the mass of > servers running are clan ports, either private or public and are therefore > purchased by clans based on there performance for their players and region. > Levelling the playing field to such a degree doesn't just reduce versatility > for server admins, clans and players it literally removes all possibility of > it. Server performance and rate "tweaking" is something clans almost require, > reports of rate abuse are ever increasing and other than using plugins/addons > (baggage attached) to control client rates (specifically cl_cmdrate) we are > powerless to prevent it. Clans want control over rates because the defaults are insufficient. Look at other games where no netcode settings are configurable and most clans don't even consider it. > At least we've ascertained that one system alone is unlikely to suit all, as > with most things in life :) Maybe an auto-rate option could be added to the > current min/max system (say setting all netrate options to 0), allowing server > admins to select auto or fixed min/max. This and the addition of sv_mincmdrate > and sv_maxcmdrate to the fixed options would provide very comprehensive > control indeed. I would definately love to see those cvar's, and I'm interested still to know why cl_rate was taken away, I mean I know you dont ever want to drop command packets, but well, hmm. > This is certainly something Valve should be looking into though. Adding server > cmdrate min/max would solve a major issue and hand off responsibility for > "rates" in general to server admins, which I feel most would welcome. Forcing > an auto system would obviously be more involved. That combined with Valve > becoming responsible for everyones netrates (baggage attached) whether they > like it or not, hmm, somehow I don't think they are willing to take such a > risk. Common sense would say that should any auto-rate system be added it > would be possible to disable it anyway, so hopefully it would be considered on > merit. It should be possible to make it entirely plug and go. To see such a thing would make me extatic, as with you, I have bandwidth to spare, and if I can use it to provide my clients with a better playing experience then bring it on. > As usual just my 1p (2 cents approx) :) You cheap *******, wouldn't even spend the whole $0.02. ;-) _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
