IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
@sotanaht
That figure is based upon user accounts with our hardware and is backed up with those videos posted in said thread.
Obviously those of us who tested this have hardware that is preferable such as SSDs... that.. currently still take over a minute to load with consistency enabled.
Meaning if you disable consistency entirely and you are still taking more time than those posted videos show (~10 seconds) then you are limited and bottlenecked by your own software/hardware installed - instead of the game - at that point.
@sotanaht
That figure is based upon user accounts with our hardware and is backed up with those videos posted in said thread.
Obviously those of us who tested this have hardware that is preferable such as SSDs... that.. currently still take over a minute to load with consistency enabled.
Meaning if you disable consistency entirely and you are still taking more time than those posted videos show (~10 seconds) then you are limited and bottlenecked by your own software/hardware installed - instead of the game - at that point.
Hey Ironhorse, is there any chance the "hitching" when walking around maps will be looked into at some point?
Surely I am not the only one with a computer sufferingr from this problem. I have noticed it regardless of settings (purposefully turned off AO to have a flat 120 FPS all the time and it still happens: going down to 0 FPS for a split second).
It is, for me, the only performance problem left in NS2 beyond end game performance (which is by far the harder thing to fix given lua).
My game is installed to an SSD, core i7930 @4.2, 570SLI @ 1080p.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
Yea dictator I'm suffering from that same problem and I've identified it as far as being due to Loading a new room (even without a single texture) while being GPU bound.
R_stats will obviously tell you if you are GPU bound with "waiting X ms for GPU"
Enabling maxfps 60 or something below your average combined with vsync triple buffering to remove the screen tears will completely remove the GPU bottle neck and thus room Loading hitching. Alternatively you can just put all settings to low.. But that makes me personally cringe.
So yeah, the issue is known but no work can be done on the renderer before this next patch unfortunately.
2 questions about consistency, because - while I completely believe IronHorse - loading a map has never taken less than 90 seconds for me (admitted it's rather old):
1.) Is there a way to see if a server has consistency checking enabled? (so I can find one that has it disabled to check that 10sec thing) - Also feel free to name a EU server if you know one.
2.) Are there different levels of consistency checking, so admins can try and find a balance between loading times and security? Or is it a binary setting?
SamusDroidColoradoJoin Date: 2013-05-13Member: 185219Members, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Gold, Subnautica Playtester, NS2 Community Developer, Pistachionauts
edited December 2013
It's really not THAT much of a difference, really. It's not like it's going to get changed anyways. It's maybe 30 seconds, a minute if it hashes all 111 level files in the PT build.
Yeah I pretty much had to stop after our main community server went down. All the alternatives are either entirely green (rest of aus servers) or can't hold ticks (US) Not one server I've found in the US (haven't tried all the ones plagued with bad mods though) can hold a tickrate mid-late game. Hitches were bad, that was the last straw.
Yea dictator I'm suffering from that same problem and I've identified it as far as being due to Loading a new room (even without a single texture) while being GPU bound.
R_stats will obviously tell you if you are GPU bound with "waiting X ms for GPU"
Enabling maxfps 60 or something below your average combined with vsync triple buffering to remove the screen tears will completely remove the GPU bottle neck and thus room Loading hitching. Alternatively you can just put all settings to low.. But that makes me personally cringe.
So yeah, the issue is known but no work can be done on the renderer before this next patch unfortunately.
Thanks IronHorse for the reply. I can imagine this will one day get worked on though given its prevalence.
Yea dictator I'm suffering from that same problem and I've identified it as far as being due to Loading a new room (even without a single texture) while being GPU bound.
R_stats will obviously tell you if you are GPU bound with "waiting X ms for GPU"
Enabling maxfps 60 or something below your average combined with vsync triple buffering to remove the screen tears will completely remove the GPU bottle neck and thus room Loading hitching. Alternatively you can just put all settings to low.. But that makes me personally cringe.
So yeah, the issue is known but no work can be done on the renderer before this next patch unfortunately.
Hmm this is odd. I am never gpu limited at the moment (lynnfield cpu at 3.6GHz combined with an oc gtx 780, since installing the gpu I always get 0ms!) But I started getting the hitches last build. Didn't get them before.
How about now is the best time to win back performance again? But it needs someone to touch their closed source code, which will probably never be released. I doubt anyone can make huge improvements by just tweaking the Lua scripts.
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
@Dictator93 & @Ironhorse
that is odd. I have a i7 930 clocked lower (3.3).
I have a 570 gtx phantom (slightly oc by default) and the game is on a Sata6g SSD.
I also run in Full HD and I do not have these hitches you describe. But Dict has a higher OCed cpu and 2 vidcards.
Just to throw it in, you did check with 1 570 to see if its not a SLI microstutter problem yes?
I must agree to some of this, there has been a significant change from build 260 to 261 in terms of performance. Never had a problem with "lag spikes" on decent servers before 261, now nearly all seem to get the red chain from time to time. Doesn't seem to be a tick issue, but more of a networking issue, as the tickrate tends to stay high during those "lag spikes" too.
The performance of this game is very good on the client side, but it does indeed need some tweaking on the server side. Statements such as "The server is too weak" isn't really the good way to go when it also applies to mainstream server hardware at the current time. For instance a Xeon E3-1275 V3 will get in trouble running a 16 slot server for this game. For a game played in 2013, this CPU should be capable of handling it without problems.
If everybody thought "Just get a better computer" or/and "Just get a better server" etc, we would never have gotten the algorithms we use the most and are dependent on these days such as HeapSort, RadixSort, B-Tree's, Binary Search, Djikstra and so on.
-
On the matter of slow loading times I don't really see the issue. This game starts in a couple of seconds from clicking the name in steam, instead of longer loads hidden behind splashscreens and videos commonly used by companies like EA etc. It has simply it's loading times put somewhere else and yes it will make you load every time a map changes, but that can give you some restitution between matches. Additionally it gives you a better security against hacks (especially memory insertions) as you can recheck things here.
On the note of consitency checking.
If this is the part that takes the most loading time, it is the efficiency of this test that can be adressed. Will us the public ever get to see the code for this? If it's a simple string comparator, does it use the Boyer Moore method? This method could and should be used in parallell by creating string sectors for it to run individual thread on. Does it use a typical compiler approach by a chargenerator going through a scanner and making tokens it compares with the tokenlist on the server's files? If so, what kind of list is this information stored in, as some are quicker to search through, but slower to add and remove from while others are the opposite.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited December 2013
@dc_darkling
Are you GPU bound, though?
That is the prerequisite for experiencing these hitches.. and just looking at your clockrates, it looks like you'd be CPU bound instead.
@roobubba
Should post some profile shots of said spikes so i can see if its the same thing (And a shot of the same exact position with r_Stats on)
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
@Ironhorse
Then I shall surprise you with a picture of a cloaked hive with the max number of entities spammed around it.
After spamming render thread went down, gpu bound went up. But both are on biodome usually around 6.
I picked biodome (I ran around) as its such a graphic map.
I will say on biodome (non nsl) I did notice SOME hitching in 'new' areas when I ran around initially on high speed as a skulk. As I am usually a tad more weary of such movement it may be linked to speed of the player.
I never experience hitches as a marine or gorge.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited December 2013
Yes you can force a gpu bound moment, but are you typically gpu bound? I always am.. Any time any where.
I7 920 @ 4ghz and a 570 gtx
Test for this hitch by starting your own server on biodome or descent, then typing in the console :
Cheats 1
J2
Lerk
R_wireframe
Profile
Now fly around (you may have to bind jump to another key because profile uses the space bar) as fast as you can in that empty map and notice that sometimes when a new room up ahead loads, you get a micro stutter or hitch. Press the space bar when this happens and take a screen shot of that frame that spikes... Bet you it says "waiting on buffered frames"
With or without SLI it would happen (have test many times).
As IronHorse said... it occurs when you are GPu bound and not CPU bound. Making my game CPU bound would be partially ridiculous given my RIG and my overclock. It is a strange case where having my graphics card being the bottleneck is a bad thing (you usually want that in a game.. .because that means your CPU is not getting in the way of your GPU doing its job).
Infact, I just tested it again ith 0 shadows flattening my FPS to 120 and about 50% GPU usage.. and it still happens. Seems that no matter what walking into a new room over loads the GPU... makes it extremely bounded and it stalls. Surely, this is not right...
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
Im just surprised I only have this hitch issue if I move very very fast from room to room, with 'less' hardware then you.
Im GPU bound @Ironhorse. For around 6 on renderer and 6 on wait for gpu, mostly.
Im just surprised I only have this hitch issue if I move very very fast from room to room, with 'less' hardware then you.
Im GPU bound @Ironhorse. For around 6 on renderer and 6 on wait for gpu, mostly.
Moving quickly exaccerbates the frame differential, but even then, you should notice your frame time dropping and hitching. For example, if you ran a benchmark you would definitely see the spikes on the graph.
I would love to kill this hitch. I would soooo love it.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited December 2013
It's the only hitch I have anymore... And i absolutely loathe it
It doesn't have anything to do with textures either (the largest memory consumption and the first culprit given the streaming nature of of it) since it happens with wire frame mode. Near as i can tell it has to do with occlusion culling somehow and a buffered frame.
(increasing max pre rendered frames or using maxfps cures it entirely)
my problem is that whenever FPS gets below the 70-80 mark, you get some really fucked up mouse smoothing/accel/whatever you want to call it. can't think of another game that does that at above 30 FPS.
my problem is that whenever FPS gets below the 70-80 mark, you get some really fucked up mouse smoothing/accel/whatever you want to call it. can't think of another game that does that at above 30 FPS.
Are you running Vsync? That would give you some intense mouse lagg with a fluctuating frame rate.
my problem is that whenever FPS gets below the 70-80 mark, you get some really fucked up mouse smoothing/accel/whatever you want to call it. can't think of another game that does that at above 30 FPS.
Are you running Vsync? That would give you some intense mouse lagg with a fluctuating frame rate.
Just spent some time examining it and trying to get it to not show up at all. I had to either adjust my resolution or my in game settings till my GPUs were working UNDER 40% utilization (was usually hovering at 20-30% gpu utlitilaztion: this is a situation you essentially never want). I just turned it down to 720p locked it at 60fps through NVCP and never got a single hitch.
Then I turned up my FPS limit to 120fps while @ 720p through NVCP and ran around biodome (60% GPU utilization). I got tiny hitches at the usual locations.. but definitely not as large had I otherwise had my FPS limit at 120 @ 1080p.
It really has to do with loading new geometry through the culling portals...
If your GPU is already @ a higher percentage of utiliation (say 70- 99 %) (even if you are getting 120fps) reaching a geometry portal over taxes the GPU for a split second... and causes a horrible stall in the pipeline.
Thinking of ways to the prevent this by adjustng settings or limiting FPS seems to be the wrong way to go at it. Honestly, there should be a much more gradual and not so system stalling way of calling in that geometry.
Otherwise, this is oddly enough punishing those who try and achiece framerates above 60 or who try and use their GPUs to their fullest (something I spent a long time getting right with Nvidia drivers for example).
I remember a long time ago the game had support for a software culling solution which was not done through visportals. Perhaps this would aid in ending these hitches ? IDK, just thinking.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited December 2013
I'm wondering if this problem is something that came about from lowering the amount of frames that are pre rendered through the DX9 API ever since reinforced patch.
The extra frame may have been buying our GPUs enough time to not stall the pipeline.. idk
IIRC That was accomplished by just changing one line of code which told the DX9 API not to do any frame limiting, since NS2 is doing its own. By default DX9 delays by 1 or 2 frames. (cant recall)
The only other thing was that priority was given more to input than rendering in that patch.. but i'm not sure that'd have much affect on this symptom.
Hmmmmm...
Comments
That figure is based upon user accounts with our hardware and is backed up with those videos posted in said thread.
Obviously those of us who tested this have hardware that is preferable such as SSDs... that.. currently still take over a minute to load with consistency enabled.
Meaning if you disable consistency entirely and you are still taking more time than those posted videos show (~10 seconds) then you are limited and bottlenecked by your own software/hardware installed - instead of the game - at that point.
Surely I am not the only one with a computer sufferingr from this problem. I have noticed it regardless of settings (purposefully turned off AO to have a flat 120 FPS all the time and it still happens: going down to 0 FPS for a split second).
It is, for me, the only performance problem left in NS2 beyond end game performance (which is by far the harder thing to fix given lua).
My game is installed to an SSD, core i7930 @4.2, 570SLI @ 1080p.
R_stats will obviously tell you if you are GPU bound with "waiting X ms for GPU"
Enabling maxfps 60 or something below your average combined with vsync triple buffering to remove the screen tears will completely remove the GPU bottle neck and thus room Loading hitching. Alternatively you can just put all settings to low.. But that makes me personally cringe.
So yeah, the issue is known but no work can be done on the renderer before this next patch unfortunately.
1.) Is there a way to see if a server has consistency checking enabled? (so I can find one that has it disabled to check that 10sec thing) - Also feel free to name a EU server if you know one.
2.) Are there different levels of consistency checking, so admins can try and find a balance between loading times and security? Or is it a binary setting?
@solaris
No to the first, yes to the second.
Hmm this is odd. I am never gpu limited at the moment (lynnfield cpu at 3.6GHz combined with an oc gtx 780, since installing the gpu I always get 0ms!) But I started getting the hitches last build. Didn't get them before.
that is odd. I have a i7 930 clocked lower (3.3).
I have a 570 gtx phantom (slightly oc by default) and the game is on a Sata6g SSD.
I also run in Full HD and I do not have these hitches you describe. But Dict has a higher OCed cpu and 2 vidcards.
Just to throw it in, you did check with 1 570 to see if its not a SLI microstutter problem yes?
The performance of this game is very good on the client side, but it does indeed need some tweaking on the server side. Statements such as "The server is too weak" isn't really the good way to go when it also applies to mainstream server hardware at the current time. For instance a Xeon E3-1275 V3 will get in trouble running a 16 slot server for this game. For a game played in 2013, this CPU should be capable of handling it without problems.
If everybody thought "Just get a better computer" or/and "Just get a better server" etc, we would never have gotten the algorithms we use the most and are dependent on these days such as HeapSort, RadixSort, B-Tree's, Binary Search, Djikstra and so on.
-
On the matter of slow loading times I don't really see the issue. This game starts in a couple of seconds from clicking the name in steam, instead of longer loads hidden behind splashscreens and videos commonly used by companies like EA etc. It has simply it's loading times put somewhere else and yes it will make you load every time a map changes, but that can give you some restitution between matches. Additionally it gives you a better security against hacks (especially memory insertions) as you can recheck things here.
On the note of consitency checking.
If this is the part that takes the most loading time, it is the efficiency of this test that can be adressed. Will us the public ever get to see the code for this? If it's a simple string comparator, does it use the Boyer Moore method? This method could and should be used in parallell by creating string sectors for it to run individual thread on. Does it use a typical compiler approach by a chargenerator going through a scanner and making tokens it compares with the tokenlist on the server's files? If so, what kind of list is this information stored in, as some are quicker to search through, but slower to add and remove from while others are the opposite.
Anyway, this game is godlike
Cheers. Chariot
Are you GPU bound, though?
That is the prerequisite for experiencing these hitches.. and just looking at your clockrates, it looks like you'd be CPU bound instead.
@roobubba
Should post some profile shots of said spikes so i can see if its the same thing (And a shot of the same exact position with r_Stats on)
Then I shall surprise you with a picture of a cloaked hive with the max number of entities spammed around it.
After spamming render thread went down, gpu bound went up. But both are on biodome usually around 6.
I picked biodome (I ran around) as its such a graphic map.
I will say on biodome (non nsl) I did notice SOME hitching in 'new' areas when I ran around initially on high speed as a skulk. As I am usually a tad more weary of such movement it may be linked to speed of the player.
I never experience hitches as a marine or gorge.
I7 920 @ 4ghz and a 570 gtx
Test for this hitch by starting your own server on biodome or descent, then typing in the console :
Cheats 1
J2
Lerk
R_wireframe
Profile
Now fly around (you may have to bind jump to another key because profile uses the space bar) as fast as you can in that empty map and notice that sometimes when a new room up ahead loads, you get a micro stutter or hitch. Press the space bar when this happens and take a screen shot of that frame that spikes... Bet you it says "waiting on buffered frames"
As IronHorse said... it occurs when you are GPu bound and not CPU bound. Making my game CPU bound would be partially ridiculous given my RIG and my overclock. It is a strange case where having my graphics card being the bottleneck is a bad thing (you usually want that in a game.. .because that means your CPU is not getting in the way of your GPU doing its job).
Infact, I just tested it again ith 0 shadows flattening my FPS to 120 and about 50% GPU usage.. and it still happens. Seems that no matter what walking into a new room over loads the GPU... makes it extremely bounded and it stalls. Surely, this is not right...
Im GPU bound @Ironhorse. For around 6 on renderer and 6 on wait for gpu, mostly.
I would love to kill this hitch. I would soooo love it.
It doesn't have anything to do with textures either (the largest memory consumption and the first culprit given the streaming nature of of it) since it happens with wire frame mode. Near as i can tell it has to do with occlusion culling somehow and a buffered frame.
(increasing max pre rendered frames or using maxfps cures it entirely)
AAAAH. I have max pre rendered on 4. As max prerendered doesnt mean it will always do 4.
Explains why I dont hitch
vsync with tripple buffer would cause many more problems.
i am not
Then I turned up my FPS limit to 120fps while @ 720p through NVCP and ran around biodome (60% GPU utilization). I got tiny hitches at the usual locations.. but definitely not as large had I otherwise had my FPS limit at 120 @ 1080p.
It really has to do with loading new geometry through the culling portals...
If your GPU is already @ a higher percentage of utiliation (say 70- 99 %) (even if you are getting 120fps) reaching a geometry portal over taxes the GPU for a split second... and causes a horrible stall in the pipeline.
Thinking of ways to the prevent this by adjustng settings or limiting FPS seems to be the wrong way to go at it. Honestly, there should be a much more gradual and not so system stalling way of calling in that geometry.
Otherwise, this is oddly enough punishing those who try and achiece framerates above 60 or who try and use their GPUs to their fullest (something I spent a long time getting right with Nvidia drivers for example).
I remember a long time ago the game had support for a software culling solution which was not done through visportals. Perhaps this would aid in ending these hitches ? IDK, just thinking.
The extra frame may have been buying our GPUs enough time to not stall the pipeline.. idk
IIRC That was accomplished by just changing one line of code which told the DX9 API not to do any frame limiting, since NS2 is doing its own. By default DX9 delays by 1 or 2 frames. (cant recall)
The only other thing was that priority was given more to input than rendering in that patch.. but i'm not sure that'd have much affect on this symptom.
Hmmmmm...