> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of StealthMode > Sent: 21 November 2005 20:23 > To: hlds@list.valvesoftware.com > Subject: RE: [hlds] cl_cmdrate.... > > Mr. Tucker, > > Did my homework, been doing my homework as a server admin > since oh 1999-2000 or so. cmdrate was in previous versions as > well. I started out on 56k dialup through aohell. So I know a > thing or two about optimizing.
I look forward to reading about it. > My cmdrate in those days was 25, and my updaterate was 30. > Those were my optimized settings with no loss no choke (even > on AOHell), unless there were network issues from the isp or the gsp. Lest we forget the average packet size is different, and more so for higher tick servers! (as is being discussed). > This new mis-use of this cvar is mostly by broadband users > who have no reason to be using a cmdrate setting that low > anyway. How big are packets coming from 100 tick servers at the different rates then? Yes, for broadband users, these are low, but not that far off: 128k upload. They say a good average for a standard CS:S server is 53.4KBits/s. (http://support.steampowered.com/cgi-bin/steampowered.cfg/php/enduser/std_adp.php?p_faqid=108&p_created=1093248464&p_sid =csCzwaVh&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTk2JnBfcHJvZHM9MCZwX2NhdHM9MCZwX3B2PSZwX2 N2PSZwX3NlYXJjaF90eXBlPWFuc3dlcnMuc2VhcmNoX25sJnBfcGFnZT0xJnBfc2VhcmNoX3RleHQ9bW9zdCBvdXQgb2Ygc2VydmVy&p_li=&p_topview=1 ) That's for default rates, and default tick. So what size is a command packet, on average? 30 packets is roughly 53.4KBits, 1 packet is therefore roughly: 1.78Kbits. 100 packets per second is therefore roughly 178Kbits per second. Now are you telling me that you honestly think a 56k modem isn't going to be having issues at higher rates? > And lets be honest, its valves game, they should be > the determiner of what the rates should be for any given > connection. Problem is its changable in its present form, and > being abused by a multitude of persons. That is indeed true, the rates should be set dynamically as has been suggested many times on this list. > Cal in its infinite wisdom stopped anyone from using a > cmdrate below 10, but this value is still too low for > broadband users. My point is simple - on a default server, playing with other clients on default settings - cl_cmdrate 10 DOES NOT produce warping or lagging effects. CAL have little wisdom - the cl_cmdrate minimum is built into the game now. > I agree a minimum of 25-30 would be nice. I do not, see values above, and reason not to. > Still not updating to the server as fast as most broadband > users (those using 100 cmdrate such as myself). In the end > its connection dependent, and I would like to see valve > determine the value based on upload speed, and once valve > determined that value it to be locked and unchangable on a > local client. Or even just remove the packet rate cvars, and stick with pure byte-wise rates, setting the packet rates based upon that. > What about slowband you say? Well, this idea I had while > reading your argument. Lets say valve had a different ruleset > for each connection type. > Lets say slowband had a maximum cap of say 50, and a minimum > cap say of 20-25. Perfectly reasonable. High, but carry on. > Lets hypothesis > further and say how about a cap of 100 and a minimum of 30 > for any broadband users. This would ensure slowband got what > they needed, and broadband got a minimum cap where it was needed. You don't NEED 30 packets per second on broadband. This stuff is carried by UDP, UDP has no knowledge of bandwidth around it, or flow control, in fact UDP makes no effort to ensure your data arrives on time, or in order. The game engine has provisions for that itself. The only time you NEED 30 packets per second or more is if you have shortened the netcode time limits. I say yet again, on defaults, it doesn't create warping. > This is what I am sure my fellow admins who are petitioning > valve (like > myself) are recommending in their private emails to valve > offlist. And I hate to say it, but a double standard would be > needed but valve would need to be the determining factor > because to be honest some people just aren't (honest). No a double standard is not required at all. There was no reason for server admins to start shortening those netcode time limits at all. They did of their own velition and now they've found a problem with it. I should hope Valve, who tested all of this (as it was available then) prior to release and came to the conclusion of what we have as defaults. You change them, you fix them. Please don't suggest global enforcement something that creates a potential abuse scenario. - This is what you are doing, and is why I went off on one at K2. > We can also look at it from this point of view. Broadband has > been out for many years in many areas. 56k is kind of like > the 300 baud modem, a thing of the past. The game's bare > minimums support 56k barely. In almost every resource I have > checked it is recommended that you get broadband if you wish > to play this game. But then, you could set your rates correctly and it works just fine - besudes, I thought you knew this with your years of optimisation experience. Facts don't soak themselves into your brain, you have to research and find out the truth, contradicting yourself is not a statement of fact. > Satelite, wireless, as you have pointed out have latency, and > should never be used for real time gaming. Please don't put words into my mouth. I said they can't be used with CS:S. There are netcode algorithms which will work over these links and much which can be done to combat the problem, that's not all real time gaming. > There are > countless articles published on the web that support this > fact. To these persons I would recommend a different type of > service if this is what they want to do with their online > time. Absolutely. > Dsl, and cable are in just about every area nowadays in > one form or another. I don't know who told you that, but they were very wrong. The world is a big place. > If they choose to play over wireless > that is their choice, and they should accept the fact they > are going to get "lag", packet choke and loss. "They" don't know that until they've suffered with it. Miseducation is killing them. > Now, to addresss the optimizations because of dialup, like I > said, broadband is recommended. See my comparison of dialup > above. And no amount of "optimizing" on your part is going to > fix a network issue with an isp. Dial up to a network issue, with no real statement of fact? What do you mean? > Because your fix today may not work tommorow, because > networks ARE that unstable. What does this have to do with over filling a small data pipe with UDP data? > Now imagine each and every time you logged into source, your > rates were determined automatically by valve servers. So no > matter how your connection was today or yesteday or tommorow, > you would have a smooth game courtesy of vALVE, in an ideal > world, this is what we would have. (Crosses fingers) Yes, the principle is right, but the method of set is incorrect. Rates should be set with a connection orientated setting, not a global setting related to speed of access to Valve servers. That has major implications immediately on a topographic scale. Connection orientated (per server as it were) settings would be suitable, and they need not be tested then set in stone - these values can be made more dynamic, and this way they can react to contention and other factors that might otherwise create unwanted effects. Did I miss the bit about optimising for 56k, or well anything? _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
