Mouserate 2ms v 8m reporting (raziel patch mx510 vs mx1000)
Moderators: Forum moderators, developers
When being behind a router that means that the NIC, the router (LAN and WAN side) and the DSL/cable modem all have to support full duplex.bani wrote:oh yes, if you're not running full duplex ethernet then you can get additional latencies of up to 50ms(!) on collisions. 10mbit full duplex is pretty rare though. you're more likely to find FD 100mbit.
Collisions should at least be pretty rare if the connection is only used for ET.
It really is about client side mouse control. Don't get me wrong, when RaZiel started posting about this, I did reply that I believe there are bigger issues than the mouse sample rate. But, there's no doubt that a higher sample rate can do 2 things for you: Give a smoother feeling (a feeling of better cursor control), possible elimination of "negative accel" (which is really just overflow in some form - clamped or uncontrolled).bani wrote:the whole mouserate thing is hilarious.
And besides that, every advantage counts.
Heh, I am likely missing something here, but I still dont see how that effects the "margin"bani wrote: doesnt matter what timestamp your client commands have, if your opponent's command gets to the server first. and network jitter will have the greatest effect on that, far more than any mouse tuning you could do. he could pull the trigger much later than you, but thanks to random network jitter (and the other sources i mentioned), his command gets there before yours... you lose, despite your mouse tuning.
No matter how large the other lags are, they are still additive I would think.
OK.
Here is the scenerio. for simplicity, this is a series of 100 1v1 smg battles between two oppenents. Resulting in two streams of input to the server. Say one opponent has higher network jitter or whatever, say higher everything you have listed before. Each of those 1v1 battles will of course have an outcome. Say the guy with the higher network jitter is also a better shot, and just for a good marginal example, say the result comes out 50 to 50, a dead tie. The different network jitter, the diferrent lags, the different skills all coallesed to create that outcome. Most of the battles were very close, with the survivor having 6 health left. the survivor kills out, and both come out with full health, and battle again. Rinse Repeat 100 times total.
Ok, the higher network jitter is there, the higher skill level is there, the battle came out even. All those different advantages, lags skill, were a wash.
Now, lets take the smg battle data streams, duplicate it exactly, yet add 6ms to all the mouse inputs to one of the players. That is going to have to result in some gameworld events of the guy with the added 6ms taking place in the next tick, ie battles that went down to one shot would have a significant probability of going the other way, the result is no longer going to be 50 50, the guy with the added 6ms to all his inputs would end up losing.
Whatever jitter or lag I have in my system, I have, just like whatever skill level I have, I have, but at the margin, additional lag on the order of 6ms, is significant if gameworld tics are somewhere near the 50ms range.
What I mean by margin:
Take swimming for example, the races are won by 100s of a second, the major thing is the swimmers strength, the swimmers technigue, his ability to turn quickly, whatever. Say this accounts for 99.9 percent of his ability to achieve a low time. Now say you have two swimmers basically evenly matched, the are 100ms apart in time. This is a MARGINAL battle. One guys shaves all his body hair, the other doesnt, the guy who shaves his body hair wins, even though relative to the strength, the technigue, etc, the gain of shaving ones hair is very minimal.
Now if that guy could improve his strength 10 percent, hell, he would win by 5 secs, but despite all his training he cannot, he is maxed out, as is his opponent. Just like if I could get rid of network jitter, I would, but I cant I suppose. But I can do marginal things like mouserate fix, its not gonna help much, but I tell you, these games we play are won by single smg battles oftentimes, they are really close.
The diffence of 6ms isnt gonna help a newer player take out an top invite player, it wont matter one bit. But it becomes important with evenly matched players I would think.
To quote myself, every advantage counts.Herf wrote:The diffence of 6ms isnt gonna help a newer player take out an top invite player, it wont matter one bit. But it becomes important with evenly matched players I would think.
Your reasoning seems good, but mind that the mouse latency is 8ms max at 125 Hz (ignoring all other mouse/usb delays). Average should be about half that. Effectively, you should get a ~3ms improvement.
It's not a whole heck of a lot, and there are lots of other things that are more significant almost all of the time.
this would only be true if both you and the other player had exactly the same ping as you, and that it was exactly constant all the time. in reality this is simply never true. it just isnt going to happen, period.Herf wrote:Now, lets take the smg battle data streams, duplicate it exactly, yet add 6ms to all the mouse inputs to one of the players. That is going to have to result in some gameworld events of the guy with the added 6ms taking place in the next tick, ie battles that went down to one shot would have a significant probability of going the other way, the result is no longer going to be 50 50, the guy with the added 6ms to all his inputs would end up losing.
one player or the other is going to win, randomly, because of things like random jitter introduced by your ISP, by the ISP of the gameserver, by the cpu and network load of the gameserver, etc. so you may often end up with having 'better' precision than the other player yet still lose.
the other problem (as i alluded to in another thread) is that you're simply not going to get 6ms precision from the engine.
there are a lot of factors going into game timing which have huge measurable effects, obsessing over mouserate milliseconds is imo a placebo. tweak it if you think it will help, but i would suggest worrying about other things which actually make a measurable difference.
and i have spent entirely too much time on this topic so this is my last post on the issue.
i havn't done any official stats comparison, but i didn't need to. the 500hz hack on an mx500/USB simply *does* make the cursor in windows much much smoother. whether or not that is helping me in ET is beyond my expertise, but suffice it to say, 500hz > 125hz. and i'm talking visual improvement here; i can see the cursor moving smoother (and feel it too)
Please direct all gameplay-changing feature requests here.
bani wrote: this would only be true if both you and the other player had exactly the same ping as you, and that it was exactly constant all the time. in reality this is simply never true. it just isnt going to happen, period.
Thanks for your time I appreciate it Bani.
For others who still are participating reading:
Nothing has to be equal for what I said to be true Bani. The only thing that has to be near equal are the RESULT of the battles. The battles results merely have to be close. It doesnt matter if my ping or lags are much greater/worse than another player if I beat that player, the only thing that matters is the results. To have a marginal battle does not require the lags to be near equal.
Marginal battles, close wins, occur all the time in ET. Escpecially in alpha matches as most people are near equal in skill.
EXAMPLE of a marginal battle:
Both players have 6 health to start out with.
PLayer A has a sum of 198ms lag (jitter+mouse rate+ping+whatever)
Player B has a sum of 100ms lag
They meet see each other and both shoot.
Player A shoots 110 ms faster than player B does, player A wins the battle. Even though his lag is higher, he wins, and he wins at the margin.
Now if player B had just missed say his cutoff for data to be included in a packet by a few ms, and then the server recieved that data, and it missed the gameworld tick and went to the next tick, he would have won that battle if his report rate of his mouse was higher.
Near misses of arbitrary cutoff points occur all the time in gaming, and in close battles they matter.
These near misses are AMPLIFIED by the fact that the gameworld ticks are say 50ms versus the 2ms 8ms difference in mouserate. Barely miss a tick you would have made with the 2ms rate, and it gets placed 50ms later. Also, the client has to arbitrarily put things into packets, there are cutoffs for these packets as well.
Say the client says at time 33339ms in game is a cutoff. Any info say 20ms before that is gonna be sent as one packet, and info after that gets put in next packet.
Say in game the fire button is pressed at time 33335, with a 2-3ms lagg it makes the cut, and is sent, if its 4-6ms later it misses the cut. A delay of 20ms total, even though the real difference is only average 3ms.
that info goes to the server, and again, the server makes a cut, Again, I dont know the specifics, but a arbitrary cut HAS to be made, the server has to think in some sort of ticks. If the packet misses the cut again, the delay compounds.
These compounding and magnified errors occur, and in MARGINAL battles, can swing the result occasionally.
Again, There is NO NEED for pings to be equal for this to occur, all that matters is that when I fight someone, the outcome is very close, the outcome already DISCOUNTS all the lags and skill differences that are there. A small change in the equation can change the result of battles. and if gameworld ticks are around the order of 50ms, then the difference of 2ms vs 8ms can be significant in marginal battles.
this assumption is incorrect.Herf wrote:if gameworld ticks are around the order of 50ms, then the difference of 2ms vs 8ms can be significant in marginal battles.
i've already gone into excruciating detail why gameworld ticks have no relationship whatsoever to client input sampling rate. they are completely asynchronous from each other. gameworld ticks only affect what a client sees not what they do.
increased mouse sampling rate might make your mouse smoother, but it simply isnt going to make you hit any player sooner. that simply isn't the way the network protocol works, the way the gameworld works, or the way the engine works.
and to get 2ms timing you'd need a constant 500fps
but the engine has various input issues way before that...I can understand, I think, the asynchronous part, its actaully key to my thought on sometimes info barely missing ticks, where if input was there faster, it would make a tick.bani wrote:this assumption is incorrect.Herf wrote:if gameworld ticks are around the order of 50ms, then the difference of 2ms vs 8ms can be significant in marginal battles.
i've already gone into excruciating detail why gameworld ticks have no relationship whatsoever to client input sampling rate. they are completely asynchronous from each other. gameworld ticks only affect what a client sees not what they do.
"gameworld ticks only affect what a client sees not what they do."
We are getting semantical here, but gameworld ticks determine if a shot is a hit or not, to me that is "doing", the server is determining if your shot is hitting or missing, that determines what I am doing at that time. The server also determines if I am dead, my client sometimes thinks I am still alive when in fact I already died. That revive I got, the "ugh" sound of my teamate, the jerk, then the teamate still being there dead on the ground. That gameworld tick on the server side affected what I did there, I did nothing but died. I can see your saying that it only effects what I see.... But then what is your defintion of do? I am either reviving a guy or not, the server decides. If your definition of do is, pressing the button, well then I would say that do would include time, did I press the button soon enough to win the battle? Again, the server decides that. In reality, I may well have press my button before the other guy, but the lags might win out over that just barely, producing a win for the other guy.
<b>If my mouse polling rate was 1 second everyone i think would agree that that would result in MANY missed gameworld ticks of info. The discussion is not over whether it occurs, its over how OFTEN it occurs with a change from 8ms to 2ms. </b>
what are gameworld ticks in increments of 40ms, 50ms? a range of 30ms to 80 ms???
There has to be some cutoff, some granularity introduced by gameworld ticks, and ones mouse input can just barely miss those ticks. Sometimes resulting in death whereas had the info made the tick, the opponent would have died.
Thanks for continuing the discussion Bani.