You registered to the forum to post that, yet you didn't bother to point out what was supposedly above my head. If it's that Adama wants to set affinity to a single core; so what? I wasn't replying to him, nor did I think it particularly promising.
Even more classic problem is prediction error. If client-side simulation has any differences from the server then it has to revert to server state. So you can have frames 1-50 using client's wrong data and then frame 51 has error so big that it's detected as prediction error and player is snapped to server position.
<!--quoteo(post=1820973:date=Jan 2 2011, 07:03 PM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Jan 2 2011, 07:03 PM) <a href="index.php?act=findpost&pid=1820973"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->So you said, but I can't even contrive a scenario where it could possibly help. I find it more likely that poor framerate is better at perceptually masking the hitching. I tried it and I can't say that I see a difference.
The 'classic' problems games designed for single-core CPUs have had with multi-core systems is the use of the RDTSC instruction without setting thread affinity to one core; which leads to jitter in the timer and jerky movement and animations, but this is not framerate hitching and does not look remotely like it. RDTSC should't be used even with thread affinity set to a single core as it doesn't measure wall-time, but CPU time in clocks; modern CPUs that can alter their clock frequency on the fly and this leads to disaster if you try and use it for measuring wall-time.
It might be helpful if you could contrive some scenario in which a thread moving around amongs the cores could cause delays of tens of milliseconds or point to some prior case where this has happened; just as proof of concept.
Can it not be both? :-)<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not going to have a battle of technicality with you right now. The basics is that when a thread moves from one core to another there is an overhead, the overhead is because the next core needs to know what state the thread is in, cached data, etc.
Now back to the topic - like I said, for me it has made a difference and I'm only trying to help by posting my findings.
Obviously I would like to play with multiple cores due to the frame rate increase so I carried on testing. Someone earlier mentioned for their system they ensured the frequencies of the CPU were not dynamic - So I looked into this further.
My gut feeling is still that this is CPU/Core related, therefore I did some monitoring and could see the CPU frequency fluctuating. So I decided to make this static in the BIOS and found that stuttering has now improved using multiple cores.
For clarity:
BIOS Disabled "Intel Speedstep" (Might not see this option if you have manually altered your clock speed, etc) Disabled "C1E Support" Saved
Windows Control Panel Power Management Ensured is on "High Performance"
Loaded up NS2
Give it a try and let me know if this has helped at all.
I apologize for not having time to read the replies in this thread, but someone emailed and requested that I address this thread. I think there at least three separate issues that are at the root of what the original poster is calling the gameplay stutter.
The simplest one is what you're observing with the leap. I believe this is an error in the Lua code for the leap where the action is not properly predicted on the client. What happens is that the client computes a different motion for the leap than the server, and when your game receives an update from the server it moves you back to the server position.
The second is periodic hitching caused by the Lua garbage collector. Our Lua code currently puts a lot of pressure on the garbage collector and I've been working on ways of rewriting the game code to improve this situation as well as making changes to the Lua VM. Almost every patch we put out has some improvements related to this and we have a change planned which will hopefully eradicate it.
The third is network "smoothness". When we started getting all of the gameplay elements together and playing full games, we discovered that the game code could be really slow on the server. For example, around Build 150 if you dropped enough Hydras you could bring an average server down to 1 frame per second. When the server is running at 1 FPS it's only sending at most 1 update to your client per second, when ideally it should be sending 20. This will result in all kinds of problems on your client, and makes it impossible to evaluate if there are actual bugs in the networking system or game code that might be causing problems.
I've put a lot of effort into improving the server performance, so it's disappointing to hear that you feel like we are ignoring this issue. Between the alpha and build 160 I think we've made huge strides here (probably around a 2000% improvement). Even with loads of Hydras the server maintains a decent update rate in the current build, but I'm still working on other improvements which I'm hoping will be ready soon.
<!--quoteo(post=1821249:date=Jan 3 2011, 09:33 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Jan 3 2011, 09:33 PM) <a href="index.php?act=findpost&pid=1821249"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I apologize for not having time to read the replies in this thread, but someone emailed and requested that I address this thread. I think there at least three separate issues that are at the root of what the original poster is calling the gameplay stutter.
The simplest one is what you're observing with the leap. I believe this is an error in the Lua code for the leap where the action is not properly predicted on the client. What happens is that the client computes a different motion for the leap than the server, and when your game receives an update from the server it moves you back to the server position.
The second is periodic hitching caused by the Lua garbage collector. Our Lua code currently puts a lot of pressure on the garbage collector and I've been working on ways of rewriting the game code to improve this situation as well as making changes to the Lua VM. Almost every patch we put out has some improvements related to this and we have a change planned which will hopefully eradicate it.
The third is network "smoothness". When we started getting all of the gameplay elements together and playing full games, we discovered that the game code could be really slow on the server. For example, around Build 150 if you dropped enough Hydras you could bring an average server down to 1 frame per second. When the server is running at 1 FPS it's only sending at most 1 update to your client per second, when ideally it should be sending 20. This will result in all kinds of problems on your client, and makes it impossible to evaluate if there are actual bugs in the networking system or game code that might be causing problems.
I've put a lot of effort into improving the server performance, so it's disappointing to hear that you feel like we are ignoring this issue. Between the alpha and build 160 I think we've made huge strides here (probably around a 2000% improvement). Even with loads of Hydras the server maintains a decent update rate in the current build, but I'm still working on other improvements which I'm hoping will be ready soon.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is exactly the reply I was looking for actually, that you'd noticed the stuttering and understand it's cause/are looking into fixing it. It's just that a lot of people had been experiencing it and as of the time of posting, there was no real acknowledgement that it existed which is why a number of us believed it was being ignored. I'm glad to see that it's being worked on, and thank you for your time!
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
great reply! you should do more blog posts perhaps about the issues and how they are beeing resolved.
I see the improvments :) that thread talks about the current problems (and not the improvments), because its what interests people most.
keep up the great work :) looking forward to the next patch (seriously, your doing a great job, this thread is here to help, no because we think you don't know what to do, but because we love the game and you gave us tools like the profiler to try to understand the issues by ourselves, its a beta test after all :) )
There's still a lot to optimize on the client (some of it is shared) - if prediction takes 20 ms per frame while not even moving then something is wrong here. Most of it spent in PhysX collisions.
20x improvement is nice to hear but there's still a lot to do since NS2 started from really slow code and billions of triangles in collision meshes.
PlasmaJoin Date: 2003-04-26Member: 15855Members, Constellation, Squad Five Blue
Max; myself and others appreciate your replies - don't get disappointed, I have definitely seen improvements since the alpha release (it was unplayable for me), now the game is playable but just hitches at some of the worst times (which I think exacerbates the 'damn this sucks' factor).
I don't know if its relevant but MOOtants post at <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=112252" target="_blank">http://www.unknownworlds.com/ns2/forums/in...howtopic=112252</a> is interesting; you probably already know/ruled that out though as a problem.
max, the leap stutter occurs for any object that moves at high velocity a shallow angle with respect to the horizontal when it clips against the ground. it happens with lerks too, if you fly into the ground at ~0-30 degrees below horizontal, you'll get the rubberband effect. i think this could be partially exacerbated by the slow server update rates.
<!--quoteo(post=1821373:date=Jan 4 2011, 05:46 AM:name=Max)--><div class='quotetop'>QUOTE (Max @ Jan 4 2011, 05:46 AM) <a href="index.php?act=findpost&pid=1821373"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I've fixed the Skulk leap prediction problem, that will be in Build 161.<!--QuoteEnd--></div><!--QuoteEEnd--> Is there a panel of all entity's predicted variables like with cl_pdump in Source or at least cl_showerror?
Kouji_SanSr. Hινε UÏкεεÏεг - EUPT DeputyThe NetherlandsJoin Date: 2003-05-13Member: 16271Members, NS2 Playtester, Squad Five Blue
<!--quoteo(post=1821373:date=Jan 4 2011, 04:46 AM:name=Max)--><div class='quotetop'>QUOTE (Max @ Jan 4 2011, 04:46 AM) <a href="index.php?act=findpost&pid=1821373"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I've fixed the Skulk leap prediction problem, that will be in Build 161.<!--QuoteEnd--></div><!--QuoteEEnd--> build 161 is sounding better with each post you make Max :)
PlasmaJoin Date: 2003-04-26Member: 15855Members, Constellation, Squad Five Blue
I was playing on a 400ms ping server a few days ago and noticed a few possible prediction problems with sound effects.
I shot my gun for example and I heard it shoot locally, then about 400ms later it then fired the sound again.
Happened to a few sounds, I think mostly guns. I noticed on even low ping servers I sometimes rarely get the double fire sound (but the 2nd fire is heard much faster than the first).
<!--quoteo(post=1821373:date=Jan 4 2011, 05:46 AM:name=Max)--><div class='quotetop'>QUOTE (Max @ Jan 4 2011, 05:46 AM) <a href="index.php?act=findpost&pid=1821373"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I've fixed the Skulk leap prediction problem, that will be in Build 161.<!--QuoteEnd--></div><!--QuoteEEnd-->
Comments
You registered to the forum to post that, yet you didn't bother to point out what was supposedly above my head. If it's that Adama wants to set affinity to a single core; so what? I wasn't replying to him, nor did I think it particularly promising.
The 'classic' problems games designed for single-core CPUs have had with multi-core systems is the use of the RDTSC instruction without setting thread affinity to one core; which leads to jitter in the timer and jerky movement and animations, but this is not framerate hitching and does not look remotely like it. RDTSC should't be used even with thread affinity set to a single core as it doesn't measure wall-time, but CPU time in clocks; modern CPUs that can alter their clock frequency on the fly and this leads to disaster if you try and use it for measuring wall-time.
It might be helpful if you could contrive some scenario in which a thread moving around amongs the cores could cause delays of tens of milliseconds or point to some prior case where this has happened; just as proof of concept.
Can it not be both? :-)<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not going to have a battle of technicality with you right now. The basics is that when a thread moves from one core to another there is an overhead, the overhead is because the next core needs to know what state the thread is in, cached data, etc.
Now back to the topic - like I said, for me it has made a difference and I'm only trying to help by posting my findings.
Obviously I would like to play with multiple cores due to the frame rate increase so I carried on testing. Someone earlier mentioned for their system they ensured the frequencies of the CPU were not dynamic - So I looked into this further.
My gut feeling is still that this is CPU/Core related, therefore I did some monitoring and could see the CPU frequency fluctuating. So I decided to make this static in the BIOS and found that stuttering has now improved using multiple cores.
For clarity:
BIOS
Disabled "Intel Speedstep" (Might not see this option if you have manually altered your clock speed, etc)
Disabled "C1E Support"
Saved
Windows
Control Panel
Power Management
Ensured is on "High Performance"
Loaded up NS2
Give it a try and let me know if this has helped at all.
And yes, it can be both ;)
The simplest one is what you're observing with the leap. I believe this is an error in the Lua code for the leap where the action is not properly predicted on the client. What happens is that the client computes a different motion for the leap than the server, and when your game receives an update from the server it moves you back to the server position.
The second is periodic hitching caused by the Lua garbage collector. Our Lua code currently puts a lot of pressure on the garbage collector and I've been working on ways of rewriting the game code to improve this situation as well as making changes to the Lua VM. Almost every patch we put out has some improvements related to this and we have a change planned which will hopefully eradicate it.
The third is network "smoothness". When we started getting all of the gameplay elements together and playing full games, we discovered that the game code could be really slow on the server. For example, around Build 150 if you dropped enough Hydras you could bring an average server down to 1 frame per second. When the server is running at 1 FPS it's only sending at most 1 update to your client per second, when ideally it should be sending 20. This will result in all kinds of problems on your client, and makes it impossible to evaluate if there are actual bugs in the networking system or game code that might be causing problems.
I've put a lot of effort into improving the server performance, so it's disappointing to hear that you feel like we are ignoring this issue. Between the alpha and build 160 I think we've made huge strides here (probably around a 2000% improvement). Even with loads of Hydras the server maintains a decent update rate in the current build, but I'm still working on other improvements which I'm hoping will be ready soon.
The simplest one is what you're observing with the leap. I believe this is an error in the Lua code for the leap where the action is not properly predicted on the client. What happens is that the client computes a different motion for the leap than the server, and when your game receives an update from the server it moves you back to the server position.
The second is periodic hitching caused by the Lua garbage collector. Our Lua code currently puts a lot of pressure on the garbage collector and I've been working on ways of rewriting the game code to improve this situation as well as making changes to the Lua VM. Almost every patch we put out has some improvements related to this and we have a change planned which will hopefully eradicate it.
The third is network "smoothness". When we started getting all of the gameplay elements together and playing full games, we discovered that the game code could be really slow on the server. For example, around Build 150 if you dropped enough Hydras you could bring an average server down to 1 frame per second. When the server is running at 1 FPS it's only sending at most 1 update to your client per second, when ideally it should be sending 20. This will result in all kinds of problems on your client, and makes it impossible to evaluate if there are actual bugs in the networking system or game code that might be causing problems.
I've put a lot of effort into improving the server performance, so it's disappointing to hear that you feel like we are ignoring this issue. Between the alpha and build 160 I think we've made huge strides here (probably around a 2000% improvement). Even with loads of Hydras the server maintains a decent update rate in the current build, but I'm still working on other improvements which I'm hoping will be ready soon.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is exactly the reply I was looking for actually, that you'd noticed the stuttering and understand it's cause/are looking into fixing it. It's just that a lot of people had been experiencing it and as of the time of posting, there was no real acknowledgement that it existed which is why a number of us believed it was being ignored. I'm glad to see that it's being worked on, and thank you for your time!
I see the improvments :) that thread talks about the current problems (and not the improvments), because its what interests people most.
keep up the great work :) looking forward to the next patch (seriously, your doing a great job, this thread is here to help, no because we think you don't know what to do, but because we love the game and you gave us tools like the profiler to try to understand the issues by ourselves, its a beta test after all :) )
20x improvement is nice to hear but there's still a lot to do since NS2 started from really slow code and billions of triangles in collision meshes.
I don't know if its relevant but MOOtants post at <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=112252" target="_blank">http://www.unknownworlds.com/ns2/forums/in...howtopic=112252</a> is interesting; you probably already know/ruled that out though as a problem.
Is there a panel of all entity's predicted variables like with cl_pdump in Source or at least cl_showerror?
build 161 is sounding better with each post you make Max :)
I shot my gun for example and I heard it shoot locally, then about 400ms later it then fired the sound again.
Happened to a few sounds, I think mostly guns. I noticed on even low ping servers I sometimes rarely get the double fire sound (but the 2nd fire is heard much faster than the first).
Oh man that is so great to hear, thank you.
if i don't take highest resolution i have 170 fps !
i will make a video soon on youtube how windows xp still beat the new windows 7-8
on NEW games !!
every gamer install windows xp ! make microsoft know we don't want there crap windows :D
btw hardware =
i7 860 3.15
8gb ram ddr3
ati hd 5870 1gb