Re: [hlds_linux] Re: Request a higher minimum value for cl_cmdrate.
On Wed, 20 Jul 2005 01:36:31, Dan Sorenson <[EMAIL PROTECTED]> wrote: > At 04:36 PM 7/18/2005 -0700, Vapor wrote: [snip] > Likely only > Valve knows how many servers run off OC192's vs. DS1's. It shouldn't be too hard to get servers to sync up with other dedicateds on the same subnet and to figure out the gateway bandwidth. tptest anyone? [snip] > Maybe it could be incorporated into the engine, and the client > elects to use it via command-line flag? -autorate as a client option > where the server updates your rates based upon what it sees as your > latency and loss might be a suitable compromise. IMO that defeats the point of such a system. The idea of an autorate system is to remove control from the users who have bad habits such as not reading docs and looking at forums filled with incorrect information. Furthermore if we are looking to balance the game in terms of making the netcode more fair for every user (the knowledgable and the not so) then you don't want it to be disabled ever. It needs to either work fully, or not, otherwise it's just an increase in the general mess. > Note to Alfred: I've not patented this idea, but if Valve likes > it I am prepared to recieve all patent royalties. Valve may also > twist my arm and force me to accept an undisclosed amount of cash > for me to sign away all rights to the idea. Valve may also send > me cash because I'm pretty and have remarkably few annoying > personal habits. No matter Valve's wishes, I'm ready to > accept cash. Please keep this in mind as you argue on my behalf. It's not just your idea (been working on this idea for some time myself, including developing a test case in a local distributed hash table system where it attempts to never swamp a gateway with data). ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Re: Request a higher minimum value for cl_cmdrate.
At 04:36 PM 7/18/2005 -0700, Vapor wrote: >I agree your ideas have merit Dan and are well intentioned, if the ultimate >scenario is everyone having "averaged" connection performance. That's all I was after. Let's face it, you'd hate to have Manchester United go up against the New York Yankees in a game of baseball because they're two entirely different games and the playing field is nowhere near level. Likewise, we'd hate to have you take on the Boston Red Sox in a game of cricket. If we're playing a game of chess, the rules are the same and the location shouldn't matter. Under Source, delay is so critical it can give an advantage. Thus it makes sense to open a discussion on keeping a public server equal for the players. >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. Keep in mind you can have gigabit connections on your LAN links to the server, but upstream your ISP is probably the limiting factor. Let's say your ISP has an OC12, at 622Mbps. An OC192 is probably the largest most ISP's get and is is 10Gbps. An OC48 is about 2.5Gbps. So if your server is at 100Mbps you're over-subscribed to all clients until you get an OC12 or better. Your server isn't the limit, it's your connection to all your clients. But that's only if you've a data center type of connection. If you're running your server over a T1 to your office or DSL to your home, all bets are off. Again, the server isn't the limit, it's the upstream path. Likely only Valve knows how many servers run off OC192's vs. DS1's. >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. I was thinking of other mods like DoD, DM Classic, and whatever comes down from the mod community. >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. As I indicated, I feel it's such a great idea that the development team could have only settled on their obviously inferior method because of other constraints. It wasn't that long ago that a 2GHz server processor was the top of the line. Perhaps it will take a 5GHz processor to make this idea usable, and I suspect the dev team had these constraints in mind when they designed the engine. >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. Maybe it could be incorporated into the engine, and the client elects to use it via command-line flag? -autorate as a client option where the server updates your rates based upon what it sees as your latency and loss might be a suitable compromise. Note to Alfred: I've not patented this idea, but if Valve likes it I am prepared to recieve all patent royalties. Valve may also twist my arm and force me to accept an undisclosed amount of cash for me to sign away all rights to the idea. Valve may also send me cash because I'm pretty and have remarkably few annoying personal habits. No matter Valve's wishes, I'm ready to accept cash. Please keep this in mind as you argue on my behalf. - Dan * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * * Vikings? There ain't no vikings here. Just us honest farmers. * * The town was burning, the villagers were dead. They didn't need * * those sheep anyway. That's our story and we're sticking to it. * ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Re: Request a higher minimum value for cl_cmdrate.
At 06:25 AM 7/15/2005 -0700, Vapor opined: >Forcing an automatic system based on rates I just can't see being effective. >What we are realistically saying here is take thousands of connection types, >speeds and latencies and have the server automatically control their update >rates. All that will be achieved would be no connection being tweakable and no >advantage seen on faster connections, all sounds nice yes, but... But that is the key to the solution, though I admit some hubris in that since I don't have to actually spend any time or effort making it work I've not seen the problems associated with it. Think of me as a member of manglement with pointy hair as you read this. Source is a hub-and-spoke network topology. The center hub is the server. Thus the server has the knowledge of rates being asked for by all clients, the latency each of them have, the jitter (difference between max and min ping time over the course of some minor time-frame), and its own load. Would it not make sense, then, (if CPU cycles were infinite and bus speed instant and memory a penny for a terabyte - yes, I know there are constraints) for the server to be able to over-ride client rate settings on a case-by-case basis by issuing new rates, starting from a baseline of your overall data rate? Let's say you've a CS server on a single T1. That's 64Kbps times 24 channels. Let's say you did 24 players. Fine, we've 64K to work with for each client. What I'm saying is that rather than have client A demand rates that would eat up 128K and client B on two tin cans and a wet string demand 2.4K, we let the server dynamically tell A "you're good, keep on, here's a little more data since you've the speed for it and I'm not missing any updates" while it tells client B (who, being an idiot because we are all plagued by idiots at some point and I need one in this scenario) set his client at T1 speeds while drooling on the string to "drop back a bit, you're missing updates." Likewise, we're all aware of ping spikes. You're running at a steady 50ms and then your wife decides to download that latest Crazy Frog video, or the Nachi worm made it onto some pointy-haired marketing-type's laptop with a gigabit ethernet connection to your switch and decides to port-scan all of New Zealand, or you've a cablemodem and the kid next door starts downloading all the pr0n in Holland. If the server could dynamically adjust rates for the clients, as the client connection changes the server would notice and could quickly adapt. >You will have millions of players blaming Valve for enforcing "their" rates, >everything from bad reg to lag will be blamed on this and uproar would >definately occur. Agreed, but do you think they'd notice if suddenly they didn't get ping spikes, and consistently had a smooth game no matter if there were 12 people or 48 people on the server? Generally the server has the bandwidth to handle 48 dsl players, but occassionally people put these things on their office T1 and start it up at night, or try to run them over 1.5M/512K DSL connections to host a few friends. Making the engine optimize the clients for the current load with some overall boundaries would satisfy a large segment of the server ops and players who don't rent servers and bandwidth from hosting firms. Only Valve would know that market share. >I pay a lot of money for my fast internet connections, I'm sure you do. Let's compare your (unknown) setup to mine. I've an OC-48 and an OC-192 into my office. My backbone routers spec out at 460Gbps until I start throwing in policy-based routing, ACL's, and the like, and they weren't exactly cheap either. I know whereof you speak, but I'm assuming that 90% of the servers out there aren't hosted at places like mine but in homes and small businesses with less spendy methods of getting bandwidth. The question to be asked here is should I be unstoppable if I take my game rig to work vs standing still if I play from home, or should we make an attempt to let the server self-adjust for its needs and force that on the clients attached? Yes, I'd be less dominant on the good connection, but less handicapped on the poorer connection. If the customer, our players, value an even playing field over that 20ms unstoppable ping to their closest server then my idea has merit. I'm not saying it's do-able, just that is has merit and should therefore be debated. >Control of client side rates must be maintained by the client, no other way >would be widely accepted by the community. And yet here's an admin asking Valve to change that because of possible abuse, which is how this thread started. >The truth of it is although we want to level the playing field and provide >fairness between all connection speeds, doing so would annoy the masses, who >are on broadband connections. You only have to look at how many ping >restricted servers are around to see
Re: [hlds_linux] Re: Request a higher minimum value for cl_cmdrate.
> Dan look over this > > http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking > > Then give a rethink of some of what you said He's mostly correct. Do know though that certain "important" entities (such as player entities) _are_ PVS-culled. -- I think poem that never as a I shall see a lovely as binary tree ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Re: Request a higher minimum value for cl_cmdrate.
Dan look over this http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking Then give a rethink of some of what you said - Original Message - From: "Dan Sorenson" <[EMAIL PROTECTED]> To: Sent: Thursday, July 14, 2005 1:06 AM Subject: [hlds_linux] Re: Request a higher minimum value for cl_cmdrate. > At 12:36 AM 7/13/2005 -0700, Eric said to all and sundry: >>>>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. > > I doubt any of that is actually transmitted to the > server. Alfred probably can't disclose much, but typically > the mouse-click is handled client-side and the action performed > is sent to the server, which responds with a result. Thus, > typical netcode will have the client report to the server > "I'm at position X.Y.Z and pointed to position A.B.C, action > is automatic fire from Super Soaker." The server takes that > information, determines if this action has a result on another > client, then informs all clients of your new location and > specific clients of the effects of your action. We're all > familiar with seeming to die at the same time a player > rounds a corner and fires, though human reaction times are > nowhere near that fast. In fact, the scene was probably played > out in the server a half-second prior, and your client is just now > getting both the "Client 1 moved to position X.Y.Z and is facing towards > A.B.C" message to generate his form and the "client 1 hit you > with eighteen gazillion damage" message that tells you to die > at about the same time. > > It would be possible for the netcode to only send updates > about client position to relevant clients, so when Client 1 moves > to a position only those with line-of-sight to that location are > updated. However, this would necessarially increase the processing > required on the server and may actually introduce more latency. > It would also eliminate wallhacks and ESP, since there's nothing > coming in for them to work with, but that could require an entire > engine overhaul and coupled with server demands there's probably > a reason it was written the way it is. > > So, in theory a server is going to be sending a bit > more data than it takes in, since it's taking in only position > and action while sending out that same info to all clients as > well as results of actions. Naturally, this is going to take > a bit of buffering in the engine to handle the wide range of > update rates that players are connected at. If I have a ping of > 200 (not uncommon given my method of connecting to the internet) > and you have a ping of 100, that's 300ms worth of player movement > and action that needs to be buffered. Let's say a half-second is > what's in buffer that the server acts upon. Let's also assume that > a cl_cmdrate of 10 means 10 updates per second to the server. > > So with a cl_cmdrate of 20, if I fire one round at > time 0.0s the server only knows that action happened between > t0.0 and t0.05, when it gets the next update. If I set my > cl_cmdrate to 10, the server only knows it happened between > t0.0 and t0.10. Suddenly I'm firing for twice as long a period. > Now the server has to figure I fired during that 10th of a second, > checks the location of you my target, and if you were within the hit > cone during that 10th of a second has to record a hit. So, by setting > my cl_cmdrate to the lowest setting single-shot weapons would > suddenly be more effective because the time they're on-target > is a 10th of a second rather than a 20th or a 30th. > > Note: all this is speculation on my part. > > So, rather than increase the cl_cmdrate minimum, what > I'd suggest is to base both cl_cmdrate and cl_updaterate off of > the old rate variable, and just make them a ratio of what the > server needs vs what it has to send. So if the server has a > maxrate of 1, and a minrate of 5000, when client 1 connects > with rate 5000 he gets cl_cmdrate 20 and cl_updaterate 30. > When he connects with rate 1 he gets cl_cmdrate 40 and > cl_updaterate 60, just to use an example. > > If we base the up and down rates as portions of the > overall rate, it should be easier for the engine to handle. > The caveat is DSL is asymetrical, so people with a 3M download > speed and a 48K upload speed might have a problem, but overall &g
[hlds_linux] Re: Request a higher minimum value for cl_cmdrate.
At 12:36 AM 7/13/2005 -0700, Eric said to all and sundry: >>>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. I doubt any of that is actually transmitted to the server. Alfred probably can't disclose much, but typically the mouse-click is handled client-side and the action performed is sent to the server, which responds with a result. Thus, typical netcode will have the client report to the server "I'm at position X.Y.Z and pointed to position A.B.C, action is automatic fire from Super Soaker." The server takes that information, determines if this action has a result on another client, then informs all clients of your new location and specific clients of the effects of your action. We're all familiar with seeming to die at the same time a player rounds a corner and fires, though human reaction times are nowhere near that fast. In fact, the scene was probably played out in the server a half-second prior, and your client is just now getting both the "Client 1 moved to position X.Y.Z and is facing towards A.B.C" message to generate his form and the "client 1 hit you with eighteen gazillion damage" message that tells you to die at about the same time. It would be possible for the netcode to only send updates about client position to relevant clients, so when Client 1 moves to a position only those with line-of-sight to that location are updated. However, this would necessarially increase the processing required on the server and may actually introduce more latency. It would also eliminate wallhacks and ESP, since there's nothing coming in for them to work with, but that could require an entire engine overhaul and coupled with server demands there's probably a reason it was written the way it is. So, in theory a server is going to be sending a bit more data than it takes in, since it's taking in only position and action while sending out that same info to all clients as well as results of actions. Naturally, this is going to take a bit of buffering in the engine to handle the wide range of update rates that players are connected at. If I have a ping of 200 (not uncommon given my method of connecting to the internet) and you have a ping of 100, that's 300ms worth of player movement and action that needs to be buffered. Let's say a half-second is what's in buffer that the server acts upon. Let's also assume that a cl_cmdrate of 10 means 10 updates per second to the server. So with a cl_cmdrate of 20, if I fire one round at time 0.0s the server only knows that action happened between t0.0 and t0.05, when it gets the next update. If I set my cl_cmdrate to 10, the server only knows it happened between t0.0 and t0.10. Suddenly I'm firing for twice as long a period. Now the server has to figure I fired during that 10th of a second, checks the location of you my target, and if you were within the hit cone during that 10th of a second has to record a hit. So, by setting my cl_cmdrate to the lowest setting single-shot weapons would suddenly be more effective because the time they're on-target is a 10th of a second rather than a 20th or a 30th. Note: all this is speculation on my part. So, rather than increase the cl_cmdrate minimum, what I'd suggest is to base both cl_cmdrate and cl_updaterate off of the old rate variable, and just make them a ratio of what the server needs vs what it has to send. So if the server has a maxrate of 1, and a minrate of 5000, when client 1 connects with rate 5000 he gets cl_cmdrate 20 and cl_updaterate 30. When he connects with rate 1 he gets cl_cmdrate 40 and cl_updaterate 60, just to use an example. If we base the up and down rates as portions of the overall rate, it should be easier for the engine to handle. The caveat is DSL is asymetrical, so people with a 3M download speed and a 48K upload speed might have a problem, but overall I think it would even out a lot of the differences between the broadband and the dial-up users. -- Dan * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * * Vikings? There ain't no vikings here. Just us honest farmers. * * The town was burning, the villagers were dead. They didn't need * * those sheep anyway. That's our story and we're sticking to it. * ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
