The gumbo of stutters, pauses, freeze and other ingredients

[The Fugitive]

Im sure they have a number of computers that are running Win10. While Skuzzy may hate WIN10, they also know a good number of their clients run win10 and so would naturally have some as a test bench at least.

[Condor]

I do wonder if it is mostly a W10 problem and HTC does not have a pc on W10?  We all known how much Skuzzy hates W10.

Nope. I use windows 7 and have the same problem.

[Chalenge]

I think the stutter issue has Microsoft as the primary cause. I think if you keep messing around you are only going to drive yourself nuts.

The same exact problem that I have with "petit-freeze" in AH3 is also hitting every single DX12 title that I own. Why it affects some DX11 title and not others is still a mystery, but it does happen.

I said this after some discussion on the upcoming Windows update for March concerning game mode. It appears that every version of Windows has been a problem for some time now. I originally suspected that something got into the mix about the time they started pushing Windows 10. On a brand new clean machine everything works fine, until you start getting updates. Eventually, there is nothing you can do to get rid of the petit-freeze issues and it is not just Aces High.

Hopefully Microsoft can sort it out with the next version.

[Pudgie]

Just putting this out here for thought...................... .

I was doing some testing on my box after upgrading my Fury X's drivers to Crimson 17.1.2......which is looking to be a fantastic driver for my vid card.......and noted that I had started to get the occasional graphics pause\freeze again when running under Dx11. The occurances were very seldom as usually noted in times past thru several driver revisions. I had made a ton of settings changes, system changes, etc which saw some occasional success at moments but nothing concrete.

This morning I got the idea to try reducing the in-game texture size from the standard size of 4096 (size the game sets itself to upon install from ID'ing my vid card) to a lesser texture size to see how all would run. I cut it to 2048 then ran the game under Dx11 and noted that the game ran very well (I especially liked the larger dot size\plane shape at distance at native res @ 2560 x 1440) and I didn't note a single screen pause to occur. Where I noted a somewhat major change is in the MSI graphs of my GPU usage as the GPU usage % actually went up w\ the GPU usage % cycling down to 0% a LOT less using the in-game texture setting of 2048 vs 4096...... I would have thought that this pattern should've been the opposite of what I saw. It is this better GPU usage pattern that I'm contributing to the absence of a screen pause\freeze at this time.

I ran w\ this setting for some time to test this out and so far, I haven't noted a screen pause occur to date under Dx11 since I reset the in-game texture size lower from 4096 to 2048 and the graphed GPU usage % shows to have increased w\ a lot less GPU usage % down cycling to 0% using 2048 vs 4096 (2048 is 1\2 of the dpi of 4096). I didn't change any other in-game settings except the texture size and didn't change any Crimson driver settings at all. This is the same type of GPU usage % patterning that I've seen when running AHIII under Dx9.........where I haven't noted any screen pauses\freezes occurring at all on my box.......................... .

Will continue to run tests but I'm beginning to wonder why would a GPU usage % load INCREASE on a lowered texture dpi size (less dpi to draw and render textures) when the bulk of this work is done post processed under Dx11?

Thus the inverse question.....why would a GPU usage % load DECREASE on a higher texture dpi size (more dpi to draw and render textures) when the bulk of this work is done post processed under Dx11?

 

Will continue testing...................... .......

 

[bustr]

Just tested offline reducing my texture to 2048 DX11. Now at super large airfields with drones in the circle with tracers firing all over the place. My FPS does not drop to 47 looking in some directions. Stays 59-60 especially on climb out looking back and down to the field which always tanked the FPS to 47 until I was past icon range.

I'll have to go online later to see if it got rid of the stutter.  2-7-17 tuesday night for squad night I used the DX11 executable and would get one stutter about every 10 minutes or so.

Wonder if 4098 is an issue for DX11?

[NatCigg]

last few days in the match play room ive been getting random hard freezes.  some are long. one second maybe 1.5.  not any complaints about warping but it bothered me.  after the freeze i would be thrust to my new position, where i should be if no time warp had happened.  fps is 30-59. depending on action.  I run :

------------------
System Information
------------------
Time of this report: 2/9/2017, 14:40:40
       Machine name: Tom Brady
   Operating System: Windows 8.1 64-bit (6.3, Build 9600) (9600.winblue_ltsb.160930-0600)
           Language: English (Regional Setting: English)
System Manufacturer: Dell Inc.
       System Model: XPS 8700
               BIOS: A08
          Processor: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (8 CPUs), ~3.6GHz
             Memory: 16384MB RAM
Available OS Memory: 16336MB RAM
          Page File: 3920MB used, 28798MB available
        Windows Dir: C:\Windows
    DirectX Version: DirectX 11
DX Setup Parameters: Not found
   User DPI Setting: Using System DPI
 System DPI Setting: 96 DPI (100 percent)
    DWM DPI Scaling: Disabled
     DxDiag Version: 6.03.9600.17415 64bit Unicode

------------
DxDiag Notes
------------
      Display Tab 1: No problems found.
        Sound Tab 1: No problems found.
        Sound Tab 2: No problems found.
          Input Tab: No problems found.

--------------------
DirectX Debug Levels
--------------------
Direct3D:    0/4 (retail)
DirectDraw:  0/4 (retail)
DirectInput: 0/5 (retail)
DirectMusic: 0/5 (retail)
DirectPlay:  0/9 (retail)
DirectSound: 0/5 (retail)
DirectShow:  0/6 (retail)

---------------
Display Devices
---------------
          Card name: NVIDIA GeForce GTX 745
       Manufacturer: NVIDIA
          Chip type: GeForce GTX 745
           DAC type: Integrated RAMDAC
        Device Type: Full Device
         Device Key: Enum\PCI\VEN_10DE&DEV_1382&SUBSYS_106510DE&REV_A2
     Display Memory: 12152 MB
   Dedicated Memory: 3984 MB
      Shared Memory: 8167 MB
       Current Mode: 1680 x 1050 (32 bit) (60Hz)
       Monitor Name: Dell E228WFP
      Monitor Model: DELL E228WFP
         Monitor Id: DELD015
        Native Mode: 1680 x 1050(p) (59.883Hz)
        Output Type: DVI
        Driver Name: nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um
Driver File Version: 9.18.0013.3266 (English)
     Driver Version: 9.18.13.3266
        DDI Version: 11
     Feature Levels: 11.0,10.1,10.0,9.3,9.2,9.1
       Driver Model: WDDM 1.3
Graphics Preemption: DMA
 Compute Preemption: DMA
           Miracast: Not Supported
Hybrid Graphics GPU: Not Supported
     Power P-states: Not Supported
  Driver Attributes: Final Retail
   Driver Date/Size: 2/16/2014 04:50:20, 18225104 bytes
        WHQL Logo'd: Yes
    WHQL Date Stamp:
  Device Identifier: {D7B71E3E-50C2-11CF-AC7F-68301FC2C435}
          Vendor ID: 0x10DE
          Device ID: 0x1382
          SubSys ID: 0x106510DE
        Revision ID: 0x00A2
 Driver Strong Name: oem64.inf:0f066de3eb4857cf:Section068:9.18.13.3266:pci\ven_10de&dev_1382&subsys_106510de
     Rank Of Driver: 00DA0001
        Video Accel:
        DXVA2 Modes: DXVA2_ModeMPEG2_VLD  DXVA2_ModeVC1_VLD  DXVA2_ModeH264_VLD_NoFGT 

[Randy1]

I have ran both AMD cards and Nividia cards and both have the same stutters.  No doubt this is a AH problem.

Pudigie on the AMD, I tried lowering the texture.  It did work for awhile then started back again.

[bustr]

Randy if you search on DX11 stutters, it's been going on with games since DX11 has been available. The spectrum of individual fixes by individual players is enormous. And in some cases getting it fixed for one game, it shows up in another. Like one player was told to update his GPU fan which fixed it for the game in question but he started experiencing in a game it didn't happen in before.

Fascinating reading all over the internet game world about this.

[Skuzzy]

I have ran both AMD cards and Nividia cards and both have the same stutters.  No doubt this is a AH problem.<snip>

We agree.  It is the most frustrating issue we have ever had to deal with.  Not being able to duplicate it and all the data not pointing to anything in particular has just been extremely frustrating.

[bustr]

Played DX11 last night with 2048 textures. First stutter didn't happen for about 30 minutes and kind of eased through and gone. Subsequent stutters were short and sharp about every 10 minutes. Looking at the ingame net stat, there was a tall sharp spike on the variance and delay line with the HOST queue unbothered. At 4096 textures stutters would start happening inside of the first 10 minutes and happen ongoing about every 5-10 minutes. Last night as numbers of players thinned out the stutters either thinned out or the periodicity started getting longer with less action going on. Being in the proximity of many players flying and driving while talking on VOX kept the stutter at every 10 minutes. I don't remember getting a freeze while in the tower.

Since I know I will get a stutter with DX11, Hitech if you want to write something that will dump memory into a file upon stutter\freeze I can post up for you. I'll go ahead and play DX11 with all the stutters to help you find an answer.

[Skuzzy]

If we knew it was happening or going to happen, we would also know where it was happening in the code, which would point us to the problem, which would lead to a patch to fix it.

It is the most vexing issue we have ever dealt with.

[bustr]

Skuzzy,

From time to time I run debug diagnostic tool to produce dumps on events. Because the stutter creates a pause and large spike in the variance and delay, any suggestions for a rule to dump on against aceshigh11.exe. Or any suggestions for running system monitor during the game to possibly capture the process in the act so I can then setup a rule for that process's act. I can experiment with the rules to try create a "dump on just about anything", and if it triggers on the spike, that should have something in the dmp file. Unless you guys have already gone through this....

[JimmyD3]

Played DX11 last night with 2048 textures. First stutter didn't happen for about 30 minutes and kind of eased through and gone. Subsequent stutters were short and sharp about every 10 minutes. Looking at the ingame net stat, there was a tall sharp spike on the variance and delay line with the HOST queue unbothered. At 4096 textures stutters would start happening inside of the first 10 minutes and happen ongoing about every 5-10 minutes. Last night as numbers of players thinned out the stutters either thinned out or the periodicity started getting longer with less action going on. Being in the proximity of many players flying and driving while talking on VOX kept the stutter at every 10 minutes. I don't remember getting a freeze while in the tower.

Since I know I will get a stutter with DX11, Hitech if you want to write something that will dump memory into a file upon stutter\freeze I can post up for you. I'll go ahead and play DX11 with all the stutters to help you find an answer.

Same here would more than willing to help on this issue. An added plus is I live here in Garland TX not too far from HTC Office.

[Pudgie]

Ran some tests........................ ..

Thinking that from all the testing that I've done that there is some kind of "code interpretation" issue concerning the game client being run thru the OS under Dx9 vs Dx11 I devised some tests to determine if there is something to that by going into the game client to try to isolate the .dll files that upon client execution signals the OS as to which Dx API version to use then observe the results. Yes I know that these tests are very crude in nature but this is the extent that I can go to at this time................

1.) I removed the D3DX9_43.dll from the game client on 2-12-17 (this .dll is supposed to be the 1 that signals the OS that Dx9 API is to be used w\ the client graphics draw calls....as I understand it's purpose of location within the game client) to see if the game client will still start up under Dx9 or fail. Upon executing the game client thru the Dx9 shortcut after removing this .dll the game actually started up normally and functioning fully---? This threw me for a surprise as I was expecting the game client to stop & give an error stating that this file was missing.....so this exercise showed to me that this .dll file isn't really needed for the AHIII game client to run under Dx9 (so it has to be provided natively thru the OS to compensate....or the actual D3DCompiler_42.dll is the file that is really needed to signal the OS to use the Dx9 API set & it is provided natively thru the OS....this .dll is not listed in the game client at all.....but the game client runs just fine). Please note that I didn't remove the D3DCompiler_47.dll from the game client (this .dll is the 1 that instructs the OS to use the Dx11 API set w\ the game client's graphics draw calls). Ran the game thru a sortie and while I was doing so I witnessed my very 1st screen freeze running under Dx9. Once I got shot down I captured the MSI graph & provided it below.
Coincidence?????????????????????????
2.) After I got home from work today I went in and removed the D3DCompiler_47.dll from the game client and attempted to execute the game client thru the Dx9 shortcut and the game once again started up normally and ran just fine w\o either of these .dll files present within the game client.....again demonstrating that the game either doesn't need these .dll files to instruct the OS to know to use the Dx9 API so the OS has to be reading the game threads to know to initiate and use the Dx9 API set by substituting the correct Dx9 .dll subset (either D3DCompiler_42.dll or D3DX9.dll) at the OS level to the client OR the shortcut's syntax when executed is instructing the OS to use the Dx9 API w\ the game client (leaning on this "suggestion" as it makes the most sense logically). Just for grins & giggles I also removed the xinput 9_1_0.dll from the game client then test the client to see if it will now refuse to start up (or the controls\mouse will not function due to this file being missing)....client started up just fine w\ full input functionality and ran just fine....once again showing to me that these files are being brought to bear thru the OS natively thru reading the game thread instructions OR by the shortcut syntax upon execution. Snippet is provided below of graph of this activity.
3.) Now I put all Dx .dll's back in the client that I had removed except the D3DCompiler_47.dll then tried to execute the client thru the Dx11 shortcut....game would not start up and got a dialog box stating "Game will not start due to D3DCompiler_*.dll missing" (note the error doesn't specifically denote that it's looking for this specific D3DCompiler_47.dll but a similar one). Same client software\code but now is refusing to start under the Dx11 shortcut w\o this D3DCompiler_47.dll being present within the client....but under the Dx9 shortcut the client starts up & runs just fine regardless of whether ANY of this is present or not within the client....except that when this particular .dll WAS present in the client & running under Dx9 was when I witnessed the very 1st screen pause on my box running the game client under Dx9 when the D3DX9.dll is NOT present within the client................. The only way the AHIII game client would start up & run under the Dx11 shortcut was when this D3DCompiler_47.dll file was inserted back into the game client and read as present in the game client file listing upon client execution into Windows..........

Hhhhmmmmm.................... ........

Now both Dx API's natively exist within the same OS version but the client seems to be able to be read natively by the OS to use Dx9 API w\o any pretext thru the game client when initially executed, but the same OS has to be expressly instructed by the same game client upon execution w\ a D3DCompiler_47.dll to use the Dx11 API instead of the "aceshigh11.exe" in the Dx11 shortcut as I'm assuming the "aceshigh9.exe" in the Dx9 shortcut is able to be read by the OS upon it's execution to use Dx9 API...........my crude tests seem to concur w\ this outcome....................

Why is this so?

In the June '10 distro of MS Dx11 there are no D3DCompiler_47 cab files present, only D3DCompiler_43 cab files (these date to Dx11.......the D3DCompiler_42 cab files date to Dx9 as does the D3DX9 cab files) & this distro is the latest version of Dx11 that I could find on MS web site.

From reading up on all the issues concerning the use of MS data link library files (.dll) it is known that these files can cause issues within an app if these files aren't identical\compatible....even an updated version of the same .dll file can cause compatibility issues of all sorts of weird stuff. It is the use of these Windows .dll files that give Windows the edge it enjoys over other OS's operating software from a compatibility standpoint but also gives Windows the problems & fits often encountered due to the very nature of these files so the importance of these files being fully compatible w\ the OS Dx API structure..............

Could this be a hidden link to this issue of screen pauses\freezes occurring due to the OS having to navigate\associate between the 2 versions of D3DCompiler_43.dll (native within OS Dx11 API vs D3DCompiler_47.dll as supplied thru AHIII game client, causing the graphics draw calls to be interrupted\delayed long enough for the OS to initiate a TDR event on a random basis)?

Or am I missing something here...................?

Something to ponder\work thru......................... .

 

[Randy1]

We agree.  It is the most frustrating issue we have ever had to deal with.  Not being able to duplicate it and all the data not pointing to anything in particular has just been extremely frustrating.

Maybe someone having the problem lives within driving distance of your office?

I have done a great deal of trouble shooting in the power plant business.  I can tell you that often, it was two problems, not one, and that the two often masked each other.

MY WAG is, as computer experts, you maybe making a change in windows or graphic software that is natural to you that most of us would not know how to do