Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
I agree your ideas have merit Dan and are well intentioned, if the ultimate scenario is everyone having averaged connection performance. I admit with being UK based I have absolutely no knowledge of server and client connections in the states but in the UK and Europe this sort of automated system would be frowned upon, heavily, for a few reasons. 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 5 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. 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. 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. I suppose it's a matter of circumstance as to which camp people fall in. I'd always assumed the majority of CS and CSS servers were rented to clans as private or public servers, not given away as community resources, I could equally be wrong though :) The same goes for my assumptions of server and client connections/bandwidth. 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. 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. 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. 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. As usual just my 1p (2 cents approx) :) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
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 5 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
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
When you decrease the cl_updaterate without decreasing the rate, then the DTT increases. On 7/16/05, Clayton Macleod [EMAIL PROTECTED] wrote: but it's not, the server takes into account your latency and the 100ms delay... On 7/16/05, James Tucker [EMAIL PROTECTED] wrote: That's not as important as the accuracy with which you aim at a model which is now up to 100ms out of place. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
yes please. On 7/13/05, Vapor [EMAIL PROTECTED] wrote: Iirc cl_cmdrate is the partner of cl_updaterate and sets how many updates are sent from client to server? Seeing as we have sv_minupdaterate and sv_maxupdaterate, why not simply add sv_mincmdrate and sv_maxcmdrate so server admins can control this themselves? I know a lot of server admins who would welcome this, low rate abuse is becoming more common every day and this is a one shot solution for Valve to hand over control (and hassle) to admins. Just me 2 cents. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
On 7/13/05, Matt Donnon [EMAIL PROTECTED] wrote: Nine updates per second is just not enough now I gotta admit that makes me curious, how many times per second can you click a mouse button? That's not as important as the accuracy with which you aim at a model which is now up to 100ms out of place. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
Above all other suggestions, why is it that the rates aren't set properly by the connection speed options? We're not on an Internet where no-one knows anything about they're connectivity anymore. Most gamers can tell you if they are on 56k, 64k, 128k, 256k, 512k, 1mb, 2mb, 6mb, 8mb or higher. Same deal with most (sensible) server operators. With that in mind, why can't the engine ask the appropriate real world human (and non-technical) questions of how much bandwidth have you got, and how many people share it?. One could go even further and run a bandwidth test first then ask how many people share it? (as it's getting very common). From there it's easy to work out what good rate values should be. I am still a little confused about sv_maxrate as there are many people who have jumped down my throat about setting too high values. The most common reason being that's over the cap, you can't have it that high, it doesn't work. My only real retort (and I won't get drawn into this argument) is that I can get a large 5mb map from my server in under 15 seconds, and no there are no res files and no sv_downloadurl. The only way to explain this is that maxrate is working at over 25 thousand bits per second. (notice the use of the word thousand as 25kbps is not 25000, one of the things that always makes me chuckle was the choice of values). As has been said in another of the responses to this thread, the default for cl_interp is 0.1. That's 100ms. With cl_cmdrate at 10 or lower that's using all of the interp time with none to spare. On top of link latencies etc you are likely looking at relatively frequent interpolation errors. This is more of an issue than bullet registration at low rates. The only way I can really see to test bullet registration is to record details of remote bot clients with most of the random input disabled. This is why I try not to discuss registration, hitbox placement and latency are far more common issues, along with FPS bounce on servers and the like. (Which by the way many of my srcds instances are still doing, on windows and linux, one running through a uk gsp is achieving 500fps over 95% of the time, but drops to 60 or so at random times during play. There is an obvious drop at the start of a round, but what I describe is mid-round and does not seem to co-incide with any significant player events. This is config independent - I have used defaults and the same occurs). I don't have the (dis)pleasure of owning a dial-up account at present, so I cannot test how much bandwidth can be streamed through 56k in the frame sizes that Source typically generates, but I suspect that for some less capable connections cl_cmdrate of 15 may be the limit. (Don't forget, up is only up and without the down the game is still un-playable). I currently configure my servers in such a way that most 56k users can't get a low enough ping to prevent being kicked by the high ping kicker. This is not because I think the game is unplayable on 56k, this is because the game is more accurate on faster connections and in terms of training, there's no point in training against targets that may or may not be where you see them. Other options for bandwidth management (although most GSP's will probably kill me for suggesting such a thing due to bandwidth costs) is to have a system which dynamically compensates based upon the choke and loss values. cl_cmdrate, updaterate, and rate could be trickle increased and decreased on the client and on the server on a continual basis, using latency, loss and choke values as an indication of the connections performance at that speed. Clearly if properly built such a system should provide the best end user experience and remove the need for users to try and understand these things. A question for Valve which has been bugging me for a while though - How many ticks of data can you fit into one client command packet? There is a cl_cmdbackup which defaults at 2. If we have 10 update packets per second, each of which contains the current command, and the previous 2, we're looking at potentially getting 30 command updates per second. The communications timeline is looking a little nasty though, cl_interp is at 0.1, so we're cutting it fine. In the event of on-time arrival of a command packet, both history packets are already more than cl_interp old, without considering link latency or data transmission time. To me these windows seem to closely matched for reliable processing, but I'm not sure exactly how the history packets are handled in that scenario. Also, is the same tick lethal damage policy FCFS? On 7/12/05, Harley Peters [EMAIL PROTECTED] wrote: I would like to request that valve increase the minimum value for cl_cmdrate. The current minimum of 10 is to low and is causing problems. Due to the fact that players are setting there cl_cmdrate to 10 because it makes there reported ping drop to 5. cl_cmdrate 10 - .8k/s - 9/s cl_cmdrate 15 -1k/s - 12/s cl_cmdrate 20 -
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
but it's not, the server takes into account your latency and the 100ms delay... On 7/16/05, James Tucker [EMAIL PROTECTED] wrote: That's not as important as the accuracy with which you aim at a model which is now up to 100ms out of place. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
Iirc cl_cmdrate is the partner of cl_updaterate and sets how many updates are sent from client to server? Seeing as we have sv_minupdaterate and sv_maxupdaterate, why not simply add sv_mincmdrate and sv_maxcmdrate so server admins can control this themselves? I know a lot of server admins who would welcome this, low rate abuse is becoming more common every day and this is a one shot solution for Valve to hand over control (and hassle) to admins. Just me 2 cents. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
I agree with Vapors suggestion on this as it would make everyone a bit more balanced on the different servers. SP_Kenny - Original Message - From: Vapor [EMAIL PROTECTED] To: hlds_linux@list.valvesoftware.com Sent: Wednesday, July 13, 2005 7:45 AM Subject: Re: [hlds_linux] Request a higher minimum value for cl_cmdrate. Iirc cl_cmdrate is the partner of cl_updaterate and sets how many updates are sent from client to server? Seeing as we have sv_minupdaterate and sv_maxupdaterate, why not simply add sv_mincmdrate and sv_maxcmdrate so server admins can control this themselves? I know a lot of server admins who would welcome this, low rate abuse is becoming more common every day and this is a one shot solution for Valve to hand over control (and hassle) to admins. Just me 2 cents. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
Nine updates per second is just not enough now I gotta admit that makes me curious, how many times per second can you click a mouse button? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
In a bold display of creativity, Matt Donnon wrote: now I gotta admit that makes me curious, how many times per second can you click a mouse button? Thousands of times, theoretically, when you consider holding the mouse button down is sending the signal that you're doing so... -- Eric (the Deacon remix) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
Matt Donnon wrote: Nine updates per second is just not enough now I gotta admit that makes me curious, how many times per second can you click a mouse button? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux It has bit more to do with it than just how often you click a mouse button. You can run your servers at 9 updates a second. Im not going to. Harley ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
now I gotta admit that makes me curious, how many times per second can you click a mouse button? Thousands of times, theoretically, when you consider holding the mouse button down is sending the signal that you're doing so... and that still only makes your weapon discharge a single round ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
In a bold display of creativity, Matt Donnon wrote: Thousands of times, theoretically, when you consider holding the mouse button down is sending the signal that you're doing so... and that still only makes your weapon discharge a single round ...if you're firing a semi-auto weapon, I guess. -- Eric (the Deacon remix) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
