PW post:
In Reply To #20
board guest 1964993 wrote:
"125mhz is already beyond anyones reflexes, you'll notice no difference putting it higher"
My reply:
You raise an interesting point about reflexes.
The patch basically takes the mouse response from 8ms to 2ms sampling.
As I understand it, there are 20hz ie 20 snaps gameworld updates. The server thinks in 50ms/20Hz increments. There is lots of different lag time, mouse lag is one, your response of your hand is another of course.
Lets say you move your hand at time x. the mouse, ignoring whatever processor lag may be there (safe to do i think) sends this over to your computer either a max of 8ms later for the normal 125 hertz mouserate, or at a max of 2ms later.
A max 6ms difference sometimes, what is possible is that, with the slower 8ms rate, your info is gonna arrive at the server with a timestamp that puts it in the NEXT 50ms game block that the server thinks in.
So lets say you have 6 health, your opponent has 6 health, and lets say you both shoot at the same time, but his info arrives at the server snap just after yours does. You win, he loses cause from servers point of view, he never got his shot off, you killed him first.
How is that for reflexes?
***************************************
So anyway, am I on the mark with that? How much better is a 2ms mousereport rate than a 8ms mousereport rate? I would think that occasionally, it could make a crucial different in battle, such as killing a panzer before he gets his shot off than next snap kinda deal. But maybe not?
I am considering trying out the mx1000, but I believe I would lose the 2ms report rate, and end up with the standard 8ms/125hz rate, and I dont think that the quoted 20x increased resolution outweighs that.....
Or perhaps both are moot, and it is beyond our reflexes?
Mouserate 2ms v 8m reporting (raziel patch mx510 vs mx1000)
Moderators: Forum moderators, developers
the whole mouserate thing is hilarious.
your average network jitter will have far more effect on the game than cranking up your mouse sampling rate.
there are a ton of things in the engine which have impacts on the game orders of magnitude larger than this.
mouse sampling rate tweaking will get lost in the background noise. go ahead and raise it all you like if you think it'll make a difference.
your average network jitter will have far more effect on the game than cranking up your mouse sampling rate.
there are a ton of things in the engine which have impacts on the game orders of magnitude larger than this.
mouse sampling rate tweaking will get lost in the background noise. go ahead and raise it all you like if you think it'll make a difference.
As far as I could gather from reading information regarding the new Razer mouse, the problem with 8ms polling is rather that X/Y offsets are send as values from -127 to 127, so it would probably become less accurate when there is too much offset between two polls, which is more likely to happen with a slow polling rate. I doubt however, that this makes much of a difference for mere mortals... Anyway, the new Razer mouse seems to solve this by simply using a larger data packet for the offset values on WinXP (and 1ms polling on other OS).
Re: Mouserate 2ms v 8m reporting (raziel patch mx510 vs mx10
One point that many people don't realize, is that not everything in the game happens at this rate. Clients get to act more often, depending on their cl_maxpackets and fps. This includes moving, shooting etc. They only get information from the server every 50 ms, but because they (usually) interpolate, it still looks smoothish.Herf wrote:PW post:
As I understand it, there are 20hz ie 20 snaps gameworld updates. The server thinks in 50ms/20Hz increments. There is lots of different lag time, mouse lag is one, your response of your hand is another of course.
I tend to agree with bani on the mouse rate thing. Do it if it makes you feel good, but on anything but a LAN and uber high end system it will be completely lost in the noise. It would be amusing to do a blind test on a few of these things.
send lawyers, guns and money
I can understand there are multiple lags/noise.
[BTW I would LOVE a post on a what actually happens when a player sees an enemy for first time and shoots. Say from start time on image appearing on players screen, to player seeing it/acting on it, to the mouse button being pressed, reported to the clients computer, tabulated on clients computer, sent to server, server tabulated and decision on whether not hit made (say hit is made), to the packet being sent back to client, the client tabulating it, then displaying it on screen. All the lags and latencies in there, that would be interesting.]
Anyway, my point is that this game is often a game played at the margin. I can understand that the mouserate difference is small, but if it just happens to barely make a packet/timestamp, when it would otherwise be incorporated in the next gameworld timestamp, that to me is significant, and since these gameworld updates are happening 20 times a second (perhaps simplified I guess) from the servers point of view, the difference of 2ms vs 8ms can at the margin make a difference in outcomes.
Everytime one wins a battle with 6 health left, and the next packet from your opponent registers a shot which is ingnored by the server, because the server deems the player dead, thats a victory at the margins.
If gameworld packets are calculated in 50ms blocks, then 6ms difference is a 12 percent chunk of that time, which is significant. The fact that there are other larger latencies doesnt matter, Because once all those are taken into account, ignoring to mouse report rate, The server is still going to put the information in one gameworld state calculation. There is a cutoff point. And if the mouse rate is 6ms quicker, at the margin of a 50ms timespamp/gameworld update, sometimes (the 12 percent figure above very roughly is a guide, I am no statitician, but in the range of 2percent to 8 percent of packets an improved mouserate from 8ms to 2ms would make the info get incorporated one packet sooner than it otherwise would, taking all the other lags into account, assuming 50ms increments of gameworld increment) that information is going to make the cutoff point instead of just missing it, resulting in basically a net 50ms difference, which win a smg battle is won by 6 health, a difference of one shot is key, likewise, killing a panzer before he gets his shot off, or a liet before he ffe's etc etc.
[BTW I would LOVE a post on a what actually happens when a player sees an enemy for first time and shoots. Say from start time on image appearing on players screen, to player seeing it/acting on it, to the mouse button being pressed, reported to the clients computer, tabulated on clients computer, sent to server, server tabulated and decision on whether not hit made (say hit is made), to the packet being sent back to client, the client tabulating it, then displaying it on screen. All the lags and latencies in there, that would be interesting.]
Anyway, my point is that this game is often a game played at the margin. I can understand that the mouserate difference is small, but if it just happens to barely make a packet/timestamp, when it would otherwise be incorporated in the next gameworld timestamp, that to me is significant, and since these gameworld updates are happening 20 times a second (perhaps simplified I guess) from the servers point of view, the difference of 2ms vs 8ms can at the margin make a difference in outcomes.
Everytime one wins a battle with 6 health left, and the next packet from your opponent registers a shot which is ingnored by the server, because the server deems the player dead, thats a victory at the margins.
If gameworld packets are calculated in 50ms blocks, then 6ms difference is a 12 percent chunk of that time, which is significant. The fact that there are other larger latencies doesnt matter, Because once all those are taken into account, ignoring to mouse report rate, The server is still going to put the information in one gameworld state calculation. There is a cutoff point. And if the mouse rate is 6ms quicker, at the margin of a 50ms timespamp/gameworld update, sometimes (the 12 percent figure above very roughly is a guide, I am no statitician, but in the range of 2percent to 8 percent of packets an improved mouserate from 8ms to 2ms would make the info get incorporated one packet sooner than it otherwise would, taking all the other lags into account, assuming 50ms increments of gameworld increment) that information is going to make the cutoff point instead of just missing it, resulting in basically a net 50ms difference, which win a smg battle is won by 6 health, a difference of one shot is key, likewise, killing a panzer before he gets his shot off, or a liet before he ffe's etc etc.
Last edited by Herf on Wed Oct 06, 2004 2:56 pm, edited 1 time in total.
network jitter from anything short of an ethernet LAN game will kill any possible edge that mouserate tuning would give you.
there's a lot of issues at work against you if you are trying to achieve eg <10ms "resolution".
network jitter from client to server, and server to client.
clock slip between server and client.
server cpu and network load
timer resolution on win32.
engine withholding snaps from client so interpolation works.
builtin command delay by client.
variable delay from client snap and other cgame processing.
variable delay from rendering the scene.
punkbuster delays
probably other stuff i forgot.
there's a lot of issues at work against you if you are trying to achieve eg <10ms "resolution".
network jitter from client to server, and server to client.
clock slip between server and client.
server cpu and network load
timer resolution on win32.
engine withholding snaps from client so interpolation works.
builtin command delay by client.
variable delay from client snap and other cgame processing.
variable delay from rendering the scene.
punkbuster delays
probably other stuff i forgot.
Bani, I think you and I are on different pages here, you know much more than I do about it of course, so perhaps we are on the same page and I dont know it.
Hmmm.
Ok ignoring mouserate for a second, and stipulating perhaps wrongly, that server works in 50ms gameworld increments/timestamps.
All those latencies you list, say they result in 500ms lag (likely I hope a larger than reality number). And say the "500ms lag"=timestamps which are 500ms later than they occured in reality.
Ok so my information hits the server 500 ms AFTER I see it on my computer screen and react to it.
There is a running stream of updates from my server to the client, the client takes these and puts them into gameworld calculations made every 50ms. Obviously, if the transmission from when I moved my mouse to the server was instantaneous, these timestamps would all be 500ms sooner, but they are not cause of all the various lags.
OK.
So now I have info (say presses of my mouse buttons during play) that have been assigned to various gameworld ticks by the server.
Now lets go back in time, and add 6ms additional lag to every one of those mouse presses. The gameworld ticks are 50ms ticks. 6ms is 12 percent of 50ms, a signifant portion of 50ms. At the margin of those 50ms ticks, 6ms is going to result in a certain percentage of those mouse presses being put into The NEXT gameworld tick, which could result in a battle lost instead of won, at the margin. I have lots of marginal battles in a game against good opponents.
My apologies for my lack of proper terminology, but to me it seems adding 6ms (4ms average??) of additional lag to a 50ms gameworld tick world is significant.
Its not resolution I am talking about, although that is a seperate issue I am interested in as well, I dont have even an unqualified opinion on it.
Hmmm.
Ok ignoring mouserate for a second, and stipulating perhaps wrongly, that server works in 50ms gameworld increments/timestamps.
All those latencies you list, say they result in 500ms lag (likely I hope a larger than reality number). And say the "500ms lag"=timestamps which are 500ms later than they occured in reality.
Ok so my information hits the server 500 ms AFTER I see it on my computer screen and react to it.
There is a running stream of updates from my server to the client, the client takes these and puts them into gameworld calculations made every 50ms. Obviously, if the transmission from when I moved my mouse to the server was instantaneous, these timestamps would all be 500ms sooner, but they are not cause of all the various lags.
OK.
So now I have info (say presses of my mouse buttons during play) that have been assigned to various gameworld ticks by the server.
Now lets go back in time, and add 6ms additional lag to every one of those mouse presses. The gameworld ticks are 50ms ticks. 6ms is 12 percent of 50ms, a signifant portion of 50ms. At the margin of those 50ms ticks, 6ms is going to result in a certain percentage of those mouse presses being put into The NEXT gameworld tick, which could result in a battle lost instead of won, at the margin. I have lots of marginal battles in a game against good opponents.
My apologies for my lack of proper terminology, but to me it seems adding 6ms (4ms average??) of additional lag to a 50ms gameworld tick world is significant.
Its not resolution I am talking about, although that is a seperate issue I am interested in as well, I dont have even an unqualified opinion on it.
i'm saying that the accumulation of random jitter from various sources will drown out any possible perceived advantage you might get from mouse tuning.
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.
also, it doesnt matter if your commands cross 50ms snap boundaries or not. gameworld action (clientcommand movement, firing, kills/deaths/etc) happens on sub-snap boundaries, the only thing snaps affect is your client's view of the world -- not your effect on it. so mousetuning will have zero effect in this case. there can (and usually is) multiple client commands per client per server frame.
this is why fps and pmove_fixed used to have such a profound effect on player movement -- accumulated rounding errors from sub-snap usercommands were heavily dependent on client's frame rate. with b_fixedphysics this is no longer the case though, at least for movement.
this is also why clients with ridiculously high fps (eg 300+) get lag problems. they are trying to send so many commands that the engine can't handle it, and drops stuff all over the floor.
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.
also, it doesnt matter if your commands cross 50ms snap boundaries or not. gameworld action (clientcommand movement, firing, kills/deaths/etc) happens on sub-snap boundaries, the only thing snaps affect is your client's view of the world -- not your effect on it. so mousetuning will have zero effect in this case. there can (and usually is) multiple client commands per client per server frame.
this is why fps and pmove_fixed used to have such a profound effect on player movement -- accumulated rounding errors from sub-snap usercommands were heavily dependent on client's frame rate. with b_fixedphysics this is no longer the case though, at least for movement.
this is also why clients with ridiculously high fps (eg 300+) get lag problems. they are trying to send so many commands that the engine can't handle it, and drops stuff all over the floor.
Does Firewall, Antivirus, Netcard-optins and other security settings affect this.. i guess so? would i send packets "faster" if i shutted down these processes..or did some netcard setup-tweaking? ..would it be noticeable?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.
All the technical stuff goes straight over my head if i'm honest. All i know is that i have always run on 200hz sampling rate via the ps2 port and i reinstalled windows recently, and i couldn't work out why the game felt jittery (checked my fps, inet connect, etconfig) and everything seemed normal. One of the last things i checked was my mouse setting, and i found that the ps2 was set to 125 hz .... changed it to 200 and everything felt smooth again
so for me this was a blind test and showed that for me at least that 200hz sampling does provide me with some benefit
By the sounds of it the higher sampling doesn't give you an advantage in how quickly your commands reach the server, but if it does make your mouse movement smoother and more accurate then it does offer an advantage imo
so for me this was a blind test and showed that for me at least that 200hz sampling does provide me with some benefit
By the sounds of it the higher sampling doesn't give you an advantage in how quickly your commands reach the server, but if it does make your mouse movement smoother and more accurate then it does offer an advantage imo
They shouldn't make a noticable difference, unless they are truely broken. When I was running my firewall/router on a 100mhz pentium, it had no detectable impact on ping, even when the CPU was under heavy load from other things.Does Firewall, Antivirus, Netcard-optins and other security settings affect this.. i guess so? would i send packets "faster" if i shutted down these processes..or did some netcard setup-tweaking? ..would it be noticeable?
10 Mbit ethernet is so much faster than your typical 'broadband' that even the crappiest ethernet hardware can usually keep up without problems. Assuming it is working correctly, there would be no gain from tweaking it.
send lawyers, guns and money