Aces High Bulletin Board
Help and Support Forums => Technical Support => Topic started by: Skuzzy on November 01, 2016, 09:38:38 AM
-
We have a ton of reports about stutters, pauses, and suspensions of the game while playing. Mostly seem to surround the DX11 version of Aces High III.
In all my readings of all the reports and all the data we have been sifting through, one thing is clear. There appears to be multiple things contributing/causing a variety of different things related to the game not playing smoothly all the time.
This is not about crashes to the desktop. That is something else. This is about the game running, but not playing smoothly. Even in that there is not playing smoothly in the DX11 version, or the DX9 version, or both. Yes between those last three, there are yet again different reasons for them acting differently.
In that cornucopia of data, some things have crept to the surface which may be some of the factors involved in causing these issues.
The purpose of this thread is to try and consolidate what players have discovered either causing or contributing to the lack of smoothness in game play.
=====
1) The removal of the Nvidia Stereoscopic 3D and Nvidia 3D Vision drivers appears to have stopped the long .5 second freeze from one computer. (DX11)
2) Making sure power management is disabled on the USB buses/ports solved short stutters in at least two cases so far. (DX11)
3) Removing/disabling the AMD/Nvidia HDMI pass-through audio drivers cured long pauses for a few players.
4) Disabling the "What U Hear" device in the audio control panel of Windows has been reported to stop the pause on microphone keying in DX11 even when Aces High III is set to use the correct device. Simply having this device enabled caused the pause.
5) Disabling skins downloads has helped, at least, one player cure the stutters. This may impact people running the game from an SSD more than those running from a hard drive.
6) Updating audio drivers also seems to help with some.
======
If anyone runs into other things which seems to have cured the stutters, please post them in this thread, and I will incorporate them into this post. Be sure to state the game version you are running (DX9, DX11 and version/patch level).
-
DX11 Just having "What U Hear" enabled caused longer pauses every time I keyed vox (posted about it too). My normal vox system is an interface via USB (also mentioned). It did not matter that AH3 was setup to use the correct device.
EDIT: Pause length was closer to 3/4 second to a full second. Currently patch 8.
-
DX11 Patch 8, Buzzsaw
Micro stutters are back, but only when I key up my mic on Vox or Range and it only hesitates once. :headscratch:
-
DX11 Patch 8, Buzzsaw
Micro stutters are back, but only when I key up my mic on Vox or Range and it only hesitates once. :headscratch:
Need a DXDIAG output.
-
DX11 Patch 8, Buzzsaw
Micro stutters are back, but only when I key up my mic on Vox or Range and it only hesitates once. :headscratch:
Having the same issue, Where do I find "What you hear" Device? I opened sounds in control panel and can't find how to disable. Attached DXdiag
-
Slate, are you expecting audio through television speakers? If not, get rid of the NVidia audio driver (disable it or remove it). It will cause problems.
-
NVIDIA TGX760 [Drivers 372.54]
SAMSUNG TC24C550 HDMI TV\Monitor, samsung Win7 drivers installed.
I use HDMI to DVI as my connection. I cannot keep Win7 from installing the hidef drivers so I disable the device. My sound is through a Plantronics GamCom 780 USB headset with mic. The Realtec onboard sound chip is disabled in the bios. The Plantronics drivers are up to date.
DX11
With patch8 on all other terrains the freeze or spike was gone until last night on buzzsaw. It happened randomly and not in sync with VOX usage or hearing VOX transmissions on squad or range. Instead of a hard lock for a second, it seemed to ease in then clear. The screen action stopped but, didn't seem to lock solid then release abruptly as in the past. I was experiencing problems with TR randomly loosing positional control and pointing my view in strange directions. I attributed that to the intense sun light reflections from the inside of my canopy being picked up as a transient light source reflected off my glasses into the TR camera. It did not happen in the tower or CV bridge, most often when flying with at least one other plane inside of 6k. In one case the plane was lower than me where I could not see it when a soft lock occurred.
-
Hello. I am experiencing frequent frame rate drops and stuttering since the latest update (as of 9:46p ET 11/2/2016) I have never had problems before and my graphics settings have not changed in Nvidia or on AH3. I noticed the recent update fixed some VR issues, could this have caused other unintended issues? Thanks
-
DxDiag attached.
-
Jimmy, in another system the player went back to stock clocks and everything smoothed back out. Would you mind trying stock clocks and see what happens?
-
Hello. I am experiencing frequent frame rate drops and stuttering since the latest update (as of 9:46p ET 11/2/2016) I have never had problems before and my graphics settings have not changed in Nvidia or on AH3. I noticed the recent update fixed some VR issues, could this have caused other unintended issues? Thanks
Frame rate drops are different from stutters. Need to see a DXDIAG output.
-
Jimmy, in another system the player went back to stock clocks and everything smoothed back out. Would you mind trying stock clocks and see what happens?
Wouldn't mind at all Skuzzy, just tell me what they are and how to do it. :cheers:
-
I must have been premature in my assessment, as the little pauses are back. I played for a few days without pauses, and now they return. It makes no sense.
-
I wonder if some reason it is server side?
Does the server get reset between maps?
Does the server get reset after an update is made?
So many people with varying systems suffer same symptoms....
I just set everything up to use DX9....can't take it anymore.
Sort of like shooting hand poured musket balls out of a sniper rifle with a high end vid card and having to fall back to DX9.
-
Jimmy, in another system the player went back to stock clocks and everything smoothed back out. Would you mind trying stock clocks and see what happens?
I don't have anything overclocked, if that is what you mean Skuzzy. :headscratch:
-
I wonder if some reason it is server side?
Does the server get reset between maps?
Does the server get reset after an update is made?
So many people with varying systems suffer same symptoms....
I just set everything up to use DX9....can't take it anymore.
Sort of like shooting hand poured musket balls out of a sniper rifle with a high end vid card and having to fall back to DX9.
We can say with 100% certainty the servers have nothing to do with the graphic issues anyone is having.
Note, the DX9 version of the game looks the same (better in some cases) than the DX11 version of the game. You are not giving up anything running the DX9 version of the game.
I don't have anything overclocked, if that is what you mean Skuzzy. :headscratch:
Odd. The default clock speed for your CPU is 3.5Ghz, yet the DXDIAG showed it running at 4Ghz. Even the boost speed of the CPU is only 3.9Ghz.
-
Dx9 2160p resolution--67fps sitting on runway.
DX11 2160p resolution--120fps sitting on runway.
I'd say I'm giving up a lot for DX9...with framerates dipping below 30 when zoomed....I'm now back at DX11.
Good to know servers are not the issue...
So next common denominator would be maps... Maybe tracking which maps generate worst stutters would be worthwhile.
I've done all the "suggestions" from other people about disabling sound drivers, uninstalling HDMI Audio component drivers, etc....stutters still exist. Didn't exist in Beta at all though...
Dobs
-
Odd, the frame rate difference, as most players get better in DX9 vs DX11.
Even those who are not getting better are only a couple of percentage points slower than DX11. Really odd that you are getting such a wide variation.
In Beta we had very few players playing it. That can make a big difference in of itself. Enough difference we have to discount what anyone got in Beta. We would have to roll out a Beta to everyone to get a basis for comparison.
-
I really think the difference between 9 and 11 is due to me being in 2160p.....
Wasn't expecting to see a big difference...surprised me.
Dobs
-
There are people running larger resolutions (triple monitor and 4K configurations) without that type of performance penalty.
-
I get micro-stutters in 1920 x 1080. Since I have DirectX 12 with Win10, and AH3 uses DX11, is there a DX11 patch I should update to, or delete DX12 and replace it with 11? How does that work?
-
DX12 is just the highest DirectX version the OS has available. Windows 10 also supports DX11, DX10, DX9 and so on, as all those versions are also installed.
Just like Windows 7 supports DX11, DX10, DX9, and so on.
-
Not sure if this is important or not but the Keyed Transmit stutter happens offline as well and shows up in the net status, see attached.
-
Odd, the frame rate difference, as most players get better in DX9 vs DX11.
Even those who are not getting better are only a couple of percentage points slower than DX11. Really odd that you are getting such a wide variation.
In Beta we had very few players playing it. That can make a big difference in of itself. Enough difference we have to discount what anyone got in Beta. We would have to roll out a Beta to everyone to get a basis for comparison.
Hi Skuzzy,
My experience is similar to Dobs......on my box I get much better FPS\game performance\smoothness from running AHIII Dx11 vs Dx9 but I also note that my CPU\GPU is taxed much less running AHIII Dx11 vs Dx9.....from looking at my graphs approx. 45%-50% less which isn't squaring w\ the fact of Dx9 creating less overhead on hardware than Dx11 but also running AHIII Dx9 I get none of the myriad of pauses\freezes I'm getting running AHIII Dx11. This gets worse when I have the Power Efficiency setting enabled (on by default in Crimson drivers) as when running AHIII Dx11 w\ PE enabled my GPU will down clock severely vs running AHIII Dx9 which causes even more stuttering simply due to lowered GPU power levels\clock speed which again isn't squaring w\ the fact of Dx9 creating less overhead on hardware vs Dx11.....all indicators on my box is stating the opposite. This has been the case since Beta Dx11 circa Patch 22 forward. I did run both the Beta Dx11 version starting w\ Patch 21 forward as well as the Dx9 version. I never got any screen pauses\freezes while running Beta Dx11 version but I did note the issue as stated w\ PE enabled vs disabled w\ Dx11 Patch 22 forward which caused a lot of stuttering due to GPU lack of power and down clocking. I also posted on this in several threads during the Open Beta period as well.......
From our experiences it clearly says that the version that Dobs & I would want to use is AHIII Dx11 from a hardware performance perspective but these "glitches" make it very annoying....as I'm sure that it does for y'all as well. From all the testing\checking that I've put into all this I'm fairly positive the issue is FE related but what exactly IS the issue(s) within the FE of AHIII Dx11 interfacing w\ Windows thru to the graphics card drivers\GPU that is causing these pauses\freezes is the mystery.
It makes sense to say that this FuryX of mine (and Dobs GTX 980Ti) should run better using Dx11 vs Dx9 as Dx11 is the prevailing D3D API being used by all the Tier I game titles so this FuryX (Dobs GTX 980Ti) was designed\drivers written and optimized w\ Dx11 performance in mind. I have recorded some graphs of running AHIII Dx11 on my FuryX w\ the in-game post-process FXAA disabled then setting the Crimson driver to override the game AA calls, set the driver AA level to 8xEQ, AA filtering to Edge Detect, AA method to Supersampling (uses the GPU to do this instead of the shaders....max driver AA settings) as well as TF set to High and this doesn't slow down this FuryX in the least (runs the same 78-80 FPS w\ slightly higher GPU usage% and a full 500-600 Mb extra mem usage) vs using the in-game FXAA setting and in fact is MUCH better looking graphically running AHIII Dx11 but when I try to run the AHIII Dx9 vers w\ the exact same settings this FuryX just will not run worth a darn....best FPS is 10 w\ GPU usage at 100%\GPU clocks at 1050 MHz\mem usage @ 1980 Mb and FT out the roof w\ stutters galore....utterly unplayable....which also again shows that for some reason AHIII Dx9 puts FAR more overhead on my hardware than AHIII Dx11 does.
I can send all this your way if y'all want it.
BUT due to the fact that when I run AHIII Dx9 using all in-game settings w\ Crimson driver set to default I get none of the issues....gameplay is near perfect vs running the same w\ AHIII Dx11....is very baffling to me. Every time I think I have it resolved it shows back up......but I also don't see this occurring as frequently on my box relative to the other players experience.
Just enough to let you know it's there. The vast majority of my playing time running AHIII Dx11 is picture perfect.
Just doesn't add up.........
Let me know if y'all need anything from me.
:salute
-
Skuzzy, when I play the DX9 version I have to turn shadows off to get the same frame rates that I get with DX11. DX( then plays smooth without dropping below 60fps, and with none of the small freezes that I get with DX11.
With DX11 I get the small freezes, but I also see what I think is the shaders being updated regularly. There will be a single frame where one 'layer' (for lack of a better term) turns white briefly (flashes) and then the shadows will flicker for a second, and then things will be what I would call 'normal' for a while until the entire thing repeats. In DX11 the atmospheric effects are more obvious (I do not even see them in DX9).
The knights are working hard to win the map at the moment, but I will try to record this now.
-
I am wondering if this has something to do with background services or processes running. It's very strange because back in early September, when I first purchased the new PC for AH3, I had zero problems with stutters and I am only now getting them after several update roll-outs. The stutters are reminiscent of back when I used to play MS Flight Simulator and automatic updates were on scanning for updates, Windows Defender was scanning in the background, and Windows was sending/receiving information in the background. Even thought I have all of these things turned off along with unnecessary services and background processes. I am going to do a fresh installation of Windows 10 and see what happens. If almost everyone is experiencing these issues it is most likely the game, but there are members of my squad with graphics maxxed our who are not experiencing these problems. I'll let you know my findings, and please share anything new you all uncover. <S> :aok
-
The flickering/flashing seems to be related to clouds and the cloud shadows. I think there is also an issue as the light fades out at dusk, but by the time I logged out, mirrored my display, and started recording it had ended. DX9 does not seem to have that problem.
It's really weird that only DX11 suffers from the pauses/freezes, but again you have to be recording when they happen. I caught few I think and I will post film and video (have to process it).
-
Skuzzy, just want to add an update on my situation, in case you might find any clues that help. I thought the mini-freezes and CTD's had stopped. Then I flew 1 sortie Thurs PM and I had several mini freezes and 2 CTD's. After logging from AH I looked and for some reason my Nvidia sound drivers were no longer disabled. This may have something to do with an "unexpected store exception" that led to the BSOD, not AH related. So I have since removed the Nvidia drivers. I flew quite a bit yesterday evening, all I think in the DX11 version, with occasional mini freezes only.
Also, I am fine with running the DX9 version is that's what it takes for now.
Dxdiag attached in case there is something here useful.
-
Last night in FSO, I knew the enemy was near by the stuttering and petite freezes that started,sure enough low 11 oclock there they were! Was over 40,maybe as many as 60 planes inside the fog ring and I was getting such bad stuttering I couldnt see tracers or who was even shooting at me.
I wasnt the only one several other players complained of the same thing!
2700K,7950,8 gigs and win7 I use low settings but had detail slider at max,post lighting off,no shadows,no AA and no bump mapping checked.
If you need a DXdiag I will have to supply that at a later time as I'm on my laptop and the wife wont let me near the game room! :furious :furious :furious
:salute
-
Oh yes, also had similar experience flyin Allies, with apparent overload and freezes when you and your numerous buddies bounced us during FSO morfiend.
-
Here is acreen shot of the Net spikes Offline when keying the Vox.....
-
I had the same experience during last Friday's FSO as described by Morfiend. Until the bandits showed up and started shooting, everything was smooth as silk. Suddenly, the mini-freezes became so rampant that I couldn't really defend myself.
SKOzone.
-
DXDIAG attached....
-
DXDIAG attached....
You might want to disable the Intel video chip in Bios, if possible.
-
I am wondering if this has something to do with background services or processes running. It's very strange because back in early September, when I first purchased the new PC for AH3, I had zero problems with stutters and I am only now getting them after several update roll-outs. The stutters are reminiscent of back when I used to play MS Flight Simulator and automatic updates were on scanning for updates, Windows Defender was scanning in the background, and Windows was sending/receiving information in the background. Even thought I have all of these things turned off along with unnecessary services and background processes. I am going to do a fresh installation of Windows 10 and see what happens. If almost everyone is experiencing these issues it is most likely the game, but there are members of my squad with graphics maxxed our who are not experiencing these problems. I'll let you know my findings, and please share anything new you all uncover. <S> :aok
That has been the biggest problem for us. We cannot duplicate it on any of our computer systems. I cannot duplicate these issue on my home system either. HiTech has played several hours in events and online as well as Waffle and cannot duplicate the stutters.
That is why we have been asking for so films. To date, there has not been anything in common with any of the films we have gotten. It is perplexing.
Now, with Windows 10, I have found numerous complaints, all over the Internet, concerning stutters in many games. With the way Microsoft does updates, we cannot pin that one down either.
It is a frustrating issue, for everyone.
-
I experimented with the AMD HDMI scaling. When I slide the slider all the way to the right, my best guess is it reduced the length of the stutters. This is so subjective, I cannot be sure of the test results.
That has been the biggest problem for us. We cannot duplicate it on any of our computer systems. I cannot duplicate these issue on my home system either. HiTech has played several hours in events and online as well as Waffle and cannot duplicate the stutters.
That is why we have been asking for so films. To date, there has not been anything in common with any of the films we have gotten. It is perplexing.
Now, with Windows 10, I have found numerous complaints, all over the Internet, concerning stutters in many games. With the way Microsoft does updates, we cannot pin that one down either.
It is a frustrating issue, for everyone.
Skuzzy, does anyone at HTC run W10?
-
Seeing freezes in DX9 today. When releasing ord from aircraft and at random times driving cross country in M3.
-
That has been the biggest problem for us. We cannot duplicate it on any of our computer systems. I cannot duplicate these issue on my home system either. HiTech has played several hours in events and online as well as Waffle and cannot duplicate the stutters.
That is why we have been asking for so films. To date, there has not been anything in common with any of the films we have gotten. It is perplexing.
Now, with Windows 10, I have found numerous complaints, all over the Internet, concerning stutters in many games. With the way Microsoft does updates, we cannot pin that one down either.
It is a frustrating issue, for everyone.
Hi Skuzzy,
After reading your post I just got a thought...................... .......
Since on the systems that y'all are running y'all can't duplicate what the rest of us are seeing it may be a help to us if y'all could post the pertinent configuration settings of these computers so that they can be used as a baseline reference for the rest of us to use to check our configurations against to see if we're missing something on our end.....like the processes and services side for starters but other items as well (w\o putting out anything proprietary to HTC's business, of course). I know I've gone thru my box SEVERAL times checking\looking for anything that could be lending to this issue but can't find anything out of place to date.
Just to share, while playing Friday night I had the game suddenly stop on me but I also got a dialog box stating that the host connection was lost then shutdown. Got to checking and noticed that my box had lost connection w\ the Internet, then saw it trying to reconnect, then lose it again, then try to reconnect, etc (have been seeing this behavior off & on for the last month). Was gonna call Centurylink to inquire but thought to check my Zoom X7N ADSL modem\router\WAP 1st and found that it had dropped the service. Went to cycle power to restart modem and found that the power switch itself & the switch latch on the X7N had burnt out of it so the modem powered off and shut down, then suddenly power back up & attempt to reconnect then once I pushed the power button to cycle power the button wouldn't latch anymore to hold the switch in to provide power. Went to Best Buy Sat morning & got a Netgear Nighthawk AC1900 D7000 WiFi ADSL\VDSL modem\router to replace the Zoom unit. Got all up and running....now I've got true 1000M LAN speed vs 100M but the weather wasn't helping (raining so warping was present) but from all this I'm not seeing the total freeze ups now....back to the occasional .5 sec freeze then resume pattern I was reporting earlier............ On 1 occasion a freeze came in conjunction w\ a player keying a mic, 1 freeze came out of nowhere and the last 1 came w\ a bunch of players massed @ A37.....this was 3 freezes within 2 1\2 hrs of gameplay all from running AHIII Patch 9 Dx11 version.
So part of my freeze\pause issue was coming from my Zoom X7N ADSL modem\router breaking down\going out on me along w\ the USB power management issue............
Now w\ this Netgear Nighthawk AC1900 I have a lot of options at my disposal to tune\tweak the LAN that I didn't have w\ the Zoom X7N so I'll be doing some more tweaking to see if I can tune the Internet side a little better.
At least I got an improvement to my total system out of all this.......can't be all bad.........
:D
:salute
-
What I have found to help (not fix) is using the NVidia control panel (possibly likewise for AMD) to set AA and AF. I set the anti-aliasing, anisotropic filtering, and maximum pre-rendered frames to = 1. This helps not only stutters a bit, but also improved input lag for me.
-
What I have found to help (not fix) is using the NVidia control panel (possibly likewise for AMD) to set AA and AF. I set the anti-aliasing, anisotropic filtering, and maximum pre-rendered frames to = 1. This helps not only stutters a bit, but also improved input lag for me.
Hi N95KF,
I also have had AF set up in Crimson drivers @ 16x for quite some time as from testing w\ it enabled vs disabled it seems to give a little better depth perception at distance thus better gunnery at distance out to a point for me & since AF doesn't provide any FPS performance hit to use so I use it. Don't really know for sure if AHIII is providing AF or not in it's code..........
As for AA I have experimented w\ using the Crimson driver side AA (GPU applied) recently which gave markedly improved graphics imagery vs the in-game FXAA (post-process AA applied thru shaders...GPU offloaded) but at this time would work only w\ the AHIII Dx11 version as when driver side AA is used w\ the AHIII Dx9 version the game becomes unplayable due to the excessive overhead derived from Dx9, FPS down less than 10 w\ macro stuttering....w\ AHIII Dx11 I saw virtually no FPS performance hit using driver side AA vs in-game post processed FXAA. I've got MSI AB graphs to verify what I have posted here as well.
As for max pre-rendered frames set @ 1, this is called Flip Quere in Radeon land & since Crimson 15.12 series AMD has changed this to be set from the old setting of 3 to 1 (don't have access to this setting from Radeon Settings....wish we did) so this has already been done to improve control input lag...if you're using an AMD graphics card that these Crimson drivers will work with. The absolute best GPU tweaking utility ever made for Radeon cards was Radeon Pro by John Maturi but can't be used now since AMD rewrote Radeon Settings in MS QT Framework (Radeon Pro was written in MS .NET Framework which was used for AMD Catalyst Control Center so it could hook into the Catalyst drivers and open up all the very same settings and more in Radeon drivers that are\were accessible to Nvidia owners thru NVCP and Nvidia Inspector utility back in the day). Since Crimson 16 series AMD has added Shader Cache and just recently w\ Crimson 16.11.2 drivers AMD has increased the Shader Cache cache size limit to improve on this even more. Slowly AMD is getting there..............
FYI........................
:aok
:salute
-
Just got done tweaking my Bigfoot Killer NIC since replacing my Zoom X7N w\ the Netgear Nighthawk AC1900 by enabling Jumbo packet & set for 9K (max size) and upped the receive & transmit buffers to the max size (2048 for receive from 512, 1024 for transmit from 256) since I now have Gigabit LAN speeds and this Killer NIC is a Gigabit capable NIC and has handshook w\ the Nighthawk at 1 Gigabit...........
Vast performance improvement across the LAN now.............getting all this across 70' of Cat 5e cable to boot!
Glad I ran it under the house instead of in the attic......have 0 electrical interference as there are no AC electrical circuits nowhere near the cable.
Will test later to see if this helps AHIII Dx11 out w\ the freezes\pauses if Internet-related........
Gonna go reset the NIC on the wife's box now..........
:salute
-
The only consistent thing I've noticed is when I experience a "mini freeze" (1/2 second or so), my FPS drops from 60 to 40 or less, and then pops back up. When I check NET STATUS, I always see a corresponding spike in the "Variance Delay" window, but I have no idea what "variance delay" means.
SKOzone
-
It's normal for your fps to drop for a moment when you encounter things like this.
Today I started playing with the Nvidia Control Panel settings and the biggest improvement has come from the setting "Maximum Pre-Rendered Frames." This option has five settings. You can set it to "Use the application setting," or choose from 1 to 4 frames. The higher the setting the smoother the result, except there may be some input lag that develops (although it will never be as bad as the input lag I get when I encounter a freeze). This may be intended to help with frame stuttering, but seems to help here too. When I had my NVCP set to application setting I was getting freezes up to 50 frames, or 50/60th of a second. At a setting of 4 I got what I think was input lag, but it was hardly noticeable, so I went with 3 and it seems to be working well.
I may put up a video explaining all of those settings now that we are out of beta.
-
It is just amazing at how many of these old graphics driver tweaks are still relevant even w\ today's hardware.
I remember back in the ATI days you could set the Flip Quere size thru the ATI control panel just as Nvidia has allowed the pre-rendered frames to be set thru the NVCP since the ForceWare driver era back during the 6000 series & up cards.......
Why AMD decided to remove this type of access to the drivers code to allow consumers to adjust stuff to better enhance GPU performance thru the graphics card's CP is beyond me and IMHO is 1 of the main reasons why AMD is in the position it's in today concerning graphics card performance as the actual hardware isn't bad at all but the choices made to set settings at the driver level to the levels that were chosen caused a fair amount of unwarranted GPU performance loss....especially w\ game titles that weren't developed w\ usage on an AMD graphics card and the nuances of it's driver stack in mind.
Sometimes trying to be different isn't the best way forward...............
:cool:
:salute
-
Just flew for 25 minutes offline DX11....no screen freezes.
Can someone else validate that please.
-
Offline has never been a problem for me that I can recall. That's why I thought it had to be something to do with the servers.
-
I started the game offline and I still get a freeze when keying mic. I can key the mic and it freezes for a second and key it the second time and it's OK. Wait a minute or so and it will freeze again. I think it is worse in DX11 than 9.
My question is weather my integrated sound is a problem and should I look into an add on sound card thinking that may solve the problem.
Some history: I have had an issue with keying the mic since AH2. Back then I would key mic it would crash to desktop and I would restart game and never have an issue with vox for the rest of my log in. I had a different Video card then (GT635). I now have a GTX1070 and that ran great in beta.
-
Slate, if you right-click the speaker icon at the lower right of your desktop, and then choose Recording Devices, how many enabled devices are listed there?
-
The DXDIAG only shows the RealTek, but the driver is really old. I would make sure there is not a later driver available.
-
Okay, after pulling my hair out for the past few weeks, I've finally figured out what was causing my stutters/micro freezes. It wasn't Windows, DX11, background processes, or driver issues...
It was..... <drumroll>
Checking 'disable players skins' in my AH3 Graphics Options!!!!
-and-
Disabling Skin Downloads in flight
If I had read the hints and tips at the top earlier, I could have avoided this issue. This should be sticky in its own category for everyone to see. I guarantee this will work for a huge chunk of the players experiencing micro-stutters.
-
Man the stutters last night were terrible, never did get rid of them. Tried DX9 and DX11, no difference I could tell. It was happening in both gv's and planes.
Is it possible an overloaded USB Hub could be causing the stutters? :headscratch:
-
Man the stutters last night were terrible, never did get rid of them. Tried DX9 and DX11, no difference I could tell. It was happening in both gv's and planes.
Is it possible an overloaded USB Hub could be causing the stutters? :headscratch:
I was seeing a lot of stutters (not freezes) last night until I disabled Win updates.
-
Here is a film that shows some of the stutters.......
WHile I have the stutters while driving straight, they show up in the film when I turn.
-
The DXDIAG only shows the RealTek, but the driver is really old. I would make sure there is not a later driver available.
Thanks Skuzzy, :salute
I downloaded new audio driver from Realtek site and I do believe it cured my Vox problem. Watching net status before there was a large spike when problem occurred. Just tested it and seems fine now. Will update if reoccurs.
Slate, if you right-click the speaker icon at the lower right of your desktop, and then choose Recording Devices, how many enabled devices are listed there?
There was always only 1. Thanks chalenge
-
Yeah, onboard sound is likely to always be a problem even when it is a lone actor.
-
Update:
This is what I have done so far and all seems to have pretty much cleared the freezes\pauses for me at this time..................
1.) I switched browsers from IE to Mozilla Firefox then imported all my favorites over to FF then shut down IE. From doing this approx 6 days ago I haven't had a screen freeze\pause since. IMHO I think that this issue was 1 of the main contributors to my issues but time will tell....... So far, so good. What got me to go here was from watching my wife playing Pogo on her box.....finally paid attention that she's using FF to run Pogo on. Got my curiosity up so I ran a test on my box.......and the rest is history.
2.) I went into my new Netgear Nighthawk AC1900 D7000 modem\router and set my box to get the highest priority in QoS and left all else as normal. Yeah I've read the other threads discussing this and so on, but if QoS is all that is available to you you use what you got as using QoS is better than nothing at all. So far after setting all this up approx the same 6 days ago I have hardly seen any Internet-induced stuttering so until this proves otherwise this also appears to be handled. The true 1 Gigabit LAN speeds I'm getting now to my Bigfoot Killer NIC is also a factor as well as maxing out the transmit and receive buffers in the NIC to help smooth out packet flow.
Now what I'm about to post may be more cosmetic than anything else but I've also noticed when I'm running AHIII Dx11 version w\ my Crimson 16.11.2 driver set to "Enhance Application Settings" instead of "Use Application Settings" for AA then set the AA method to either "Adaptive Multisampling" or "Supersampling" the graphics look much, much better in every way. But the main thing that I've noticed w\ regards to the topic of this thread is that by using this combination this actually puts enough of an extra load on my GPU to get the GPU usage up to within the 70%-80% range where the game really does smooth out. This is also 1 of the items that--I'll say it again--I've noticed on my box running the AH Dx11 version since the Beta Patch 22 days forward across several Crimson driver versions.....on my box using the AH Dx11 version the GPU usage% load reduces a fairly large amount vs when running the AH Dx9 version using the exact same game\driver settings. Now this may not seem like much to some but the issue w\ this IMHO is centering around the AMD PowerTune 2.0 GPU control (same as GPU Boost 2.0 for Nvidia) reacting to this especially concerning the amount of power regulation supplied to the GPU due to the way PowerTune 2.0 works. For PowerTune 2.0 or Nvidia GPU Boost 2.0 to work efficiently the graphics rendering level settings as noted thru the DRIVERS, whether from the game itself or the drivers itself or any combination of the 2 are used to calculate the amount of power to apply to maintain the necessary GPU clock speed to render the work smoothly according to the actual GPU operational temps at hand....think "power per watt" here. From all my testing of these control programs (I've tested both of these extensively in times past and have the AMD engineering white papers on how PowerTune 2.0 actually works) the higher the graphics rendering level settings are PowerTune 2.0 will calculate to apply more power and allow the GPU to clock up and optimize GPU rendering performance as long as the GPU operating temps are\stay JUST below the BIOS-set GPU temp TDP threshold, but if the graphics rendering level settings are set too low, regardless of if\how far the GPU operating temps are below the TDP, both of these control programs WILL REDUCE the power output to the GPU due to the control calculating that according to the graphics rendering settings LEVELS the GPU shouldn't NEED above a certain amount of GPU power applied to do the work even though for a brief instance(s) due to various varibles the GPU may need to have more power applied to get thru it and thus may create a stutter but even potentially down to a GPU stall. Since AH Dx9 shows to put more of a graphics rendering load on my Fury X's GPU than AH Dx11 does (by approx 40%-50% more when viewed thru GPU usage % using the exact same in-game\driver graphics settings levels) that this has to be a contributor as well to the freezing\pausing going on mostly w\ AH III Dx11 version relative to the AH III Dx9 version......I believe is due to some coding difference(s) within the 2 versions of Dx that is causing the vast GPU usage % differences (GPU load vs power). This gets MUCH worse if Power Efficiency is enabled in the Crimson driver (when this is disabled it tells PowerTune 2.0 to allow the GPU clocks to go full instead of controlling them but I don't think this also disables the PowerTune 2.0 GPU power calcs....I think the same may prove out for Nvidia's GPU Boost 2.0 when you set the driver to prefer maximum performance vs adaptive but can't be for sure w\o actually testing it now vs when I did prove this some 1 1\2-2 yrs back when I ran a test between a GTX 780Ti vs a Radeon R9 290X on my prior X79 box). This could also very well be due to Dx11's Shader Model 5.x being more efficient vs Dx9's Shader Model 3.x performing the post-processing rendering work in AHIII which offloads the GPU much more (not to mention that these more modern graphics cards of either stripe are designed\tuned at the GPU\driver level to get more efficiency out of Dx11 than Dx9 since the vast majority of games out for some time have been written to use\optimize Dx11 and AH has now recently incorporated Dx11).
Could be as easy as doing some in-game post processing graphics rendering output level tuning (we don't have access to do this....only HTC does) to fix all this for the Dx11 version of the game...........which may call for the game to be physically separated into 2 fully separate AH III game versions..........
Just a thought......................
Anyway, hope this helps.
:salute
-
Posted this on another thread, but found my screen stutters, my Firewall was set on "Automatic" switched it to "Interactive" stutters stopped. I was getting stutters all the time, in gv's or planes. As of today everything is back to normal.
-
Posted this on another thread, but found my screen stutters, my Firewall was set on "Automatic" switched it to "Interactive" stutters stopped. I was getting stutters all the time, in gv's or planes. As of today everything is back to normal.
What operating system are you using? I do not see an interactive setting.
I'm using Windows 10 64Bit.
Coogan
-
I think that's pre-Windows 8.
-
I think that's pre-Windows 8.
Ahh, thank you.
Coogan
-
When I experience a freeze, I quickly check Net Status and I always see an accompanying "
Variance Delay" spike. Does anyone know what this means, or what it indicates?
SKOzone
-
When I experience a freeze, I quickly check Net Status and I always see an accompanying "
Variance Delay" spike. Does anyone know what this means, or what it indicates?
SKOzone
FYI I've noticed this too. I can see how these freezes are driving HTC nuts. Seems on my end anyway that there's really no rhyme or reason to them. I'll get them in a fight or flying straight and level. Up high, down low. A bunch almost right in a row and none for a while. Some are the half second variety, some are a hard video freeze that only the 3 finger salute cures. But the one thing in common is they only seem to be happening to me when I'm online. Offline I don't recall it happening.
Sent from my XT1585 using Tapatalk
-
When I experience a freeze, I quickly check Net Status and I always see an accompanying "
Variance Delay" spike. Does anyone know what this means, or what it indicates?
SKOzone
Hi SKOzone,
The "Variance Delay" is a means of AH III software measuring the Internet packet sequence streaming in milliseconds from the moment the packets arrive to the NIC (network interface card) until they reach the game to be processed. The bottom of the line is usually representing the fastest the packets are traveling to the game and is considered to be the "baseline" measurement, so any spike up from this line is representing a slowdown (or variance delay) of the packet sequence streaming from the NIC to the game. AH III uses this data to make the adjustments that it makes to maintain a smooth game function as HTC knows that this packet sequencing stream will not stay constant.
When you see a very large spike this is indicating that the packet sequencing stream has slowed down considerably or even actually stopped for the amount of time shown before the packet sequencing stream returned back to a more normal pace. The higher the spike, the longer the amount of time has elasped between the last packet received to the next packet in sequence to be received.
Hope this helps you out w\ that.
There are several things that can cause this spike to occur but you're seeing it in conjunction w\ the screen freeze\pause. At the same time your vid card's GPU has also stopped rendering\flipping graphics frames to display (I have graphed this happening as well as the variance delay spike happening within the same\nearly the same instance of time) then either it will resume operation on it's own or the screen will remain froze (GPU has clocked down to 0 and is non-responsive) so the game has to be shut down to clear the faults then restarted to recover.
This is occurring w\ both Dx versions but the vast majority of these are occurring w\ the AH III Dx11 version of the game.
The 1 thing I haven't heard to date is if the VR users who are using the Dx11 version are having\seeing these same issues occurring w\ their headsets.
:salute
-
IIRC it is still unclear which comes first, the spike or the freeze. Which is the cause, which is the symptom?
-
Thank you for the excellent explanation, Pudgie. It makes me wonder, however, if it could be an issue with my router configuration. Perhaps packets are being lost or blocked.
During last night's FSO, the freezes were particularly frequent when many aircraft where in the sky with me. As I was attacking a large bomber formation, it happened a number of times, but as I zoomed away, the freezes almost ceased. Could this be due to the fact that the HTC servers didn't have to update as many aircraft positions as I streaked out of icon range?
-
What operating system are you using? I do not see an interactive setting.
I'm using Windows 10 64Bit.
Coogan
Actually I'm running Windows 7 Pro
-
The petit-freeze issue has returned with NDIsles and Buzzsaw. I am hoping that when CraterMA returns that there freezes will also disappear. On Buzzsaw I am also starting to see the game minimize on me. So far the game has always returned to focus and I have been lucky not to have been at low altitude at the times that it has happened. Unless it was the latest patch that caused this, it could be something to do with these two maps.
-
How many people have been using the Fast Sync feature of their Nvidia cards who have stutters here?
I know I have.....going to try Vsync and triple buffering and see if I get them.
Reason I ask is this:
https://forums.geforce.com/default/topic/940039/gtx-1080-fast-sync-problems/
-
Just ran a test running AHIII offline on my box under Dx11 and got a screen freeze within 5 mins of upping to attack the token ring.
Screen locked up but game kept running....had to do the 3 finger salute to Task Manager and force the game to exit.
Captured a snippet of my MSI Afterburner graph which shows the GPU didn't clock down to 0 as it did during a prior instance when I was online, all kept running but the screen was locked. Noted typical CPU core usage pattern when running the game under Dx11 of Core1 and Core4 being mostly utilized.
:salute
-
How many people have been using the Fast Sync feature of their Nvidia cards who have stutters here?
I know I have.....going to try Vsync and triple buffering and see if I get them.
Reason I ask is this:
https://forums.geforce.com/default/topic/940039/gtx-1080-fast-sync-problems/
The problem of pause-and-play/petit freeze/hesitations is very much like triple-buffering, but I don't think triple-buffering is possible in a DirectX game. There was a utility written that forces triple-buffering to work, but I have not tried that one yet. I think it is included as part of the Riva Tuner utility. It is called the Direct3D Overrider, or D3DOverrider.
-
I have started to use the game booster application Razer Cortex which allows a user to turn off processes, services, and what have you before launching a game. It is a lot like AlacrityPC in that regard. Also, I have begun running the MSI Afterburner app to overclock the video cards. This has eliminated nearly all issues, except the pause-and-play issue. The Razer Cortex was especially handy in trimming down all the apps that share dat, update in the background, and do other things that may cause the foreground stuttering issue. Using Afterburner just helps to make sure the frame rates don't dip in the heavier wooded sections.
What I found is that you can push the overclock of the video too far, which doesn't cause an issue with the cards, but can cause things like the AH3 water to flicker even worse than the cloud shadows do. However, overclocking also eliminated the cloud flicker, or HTC adjusted something, because the flicker is gone now and the sun shining through the clouds causes a change in lighting intensity. I much prefer that.
The pause-and-play issue is causing flight to lack fun completely. Takeoffs and landings are especially prone, as are engagements. The point at which you have a firing solution will see one nearly every time. The only thing I have left to try is moving voice off to a second system, which will eliminate using in game vox and is obviously not an ideal solution.
-
The problem of pause-and-play/petit freeze/hesitations is very much like triple-buffering, but I don't think triple-buffering is possible in a DirectX game. There was a utility written that forces triple-buffering to work, but I have not tried that one yet. I think it is included as part of the Riva Tuner utility. It is called the Direct3D Overrider, or D3DOverrider.
Actually, the graphic engines in Aces High (2 & 3) have always done triple-buffering. It would be a bad idea to enable it in the video card driver.
-
I have managed to at least minimize the "mini freezes" to the level of occasional annoyances by completely uninstalling and then re-installing Aces High. That made a very noticeable difference. Then, disabling any other audio devices through Device Manager improved it further.
Disabling the other audio devices (the RealTek driver, plus two other USB audio devices) is a bit of a pain as I use them for other applications. I disable them before I go flying and then re-enable them when I am done.
For Aces High I am using an old Plantronics DSP USB headset with the Microsoft Windows driver. Maybe it is time for a new headset with a native driver. It is worth trying to see if I can eliminate the last of the freezes.
SKOzone
-
So turned Vsync on (no triple buffering) and flew a few sorties...
Things that I noticed....crazy shadow flicker from clouds (not visible with Fast Vsync enabled...running on average 100+FPS in 4k), and screen stutter in turns over the water near CV with clouds present.
The latter made me turn vsync back to Fast.
Mini freezes both ways...
-
I forced triple-buffering on just to see, and while using the D3DOverrider. There was zero difference, except that the shadows under clouds was flickering again. I have moved my mixer to the recording system, so it has zero influence on my gaming system now. My mic line is still passing through a USB interface, which could be causing a problem and it is the last place I can look for an issue on this system. If turning that off doesn't fix it then I will be going, reluctantly, to DX9.
-
While I was dinking around online today I read up on the topic of CPU core affinity and came upon the process of going thru the Task Manager to assign CPU affinity to a process so I started up AHIII Dx11 then went into Task Manager, right clicked on the game process then set CPU affinity to use only the 1st 2 CPU cores instead of all 6 then went back into AHIII and carried on to play.
Upped at A1 and I immediately noticed that the petite freezes that Chalenge referred to seeing were now gone (I had always looked at these as GPU stuttering prior until recently). I saw none of this anymore even when making rapid movements in game. All screen motion was butter smooth. After flying around for a little longer I exited out (got shot down by OUTATIME on a 6 o'clock bounce), pulled up MSI AB graphs to see the CPU core usage....now I could see distinctly that 2 CPU cores were being used even though the CPU core usage % was still pretty low.
So I ran AHIII Dx11 again setting CPU core affinity to use 2 cores, upped from A1 again....I got none of the petite freezes this run as well and was getting pretty happy about all this. Tangled up w\ OUTATIME again and was working the fight when I got a 1.5 sec screen pause right when I was rolling over the top of an Immelman to come down on his 6.......went on and finished the fight and shot down OUTATIME then exited the game and pulled the graph up and moved the tracer line over the screen pause where GPU clocks dropped and frametime spiked then traced it down to the CPU usage % of Core 1 and Core 2 and it showed Core 1 at 34% and Core 2 at 21%.
Ran test 2 more times to verify the petite freeze pattern and verified that by setting the CPU core affinity to 2 cores instead of using all 6 cores, this stopped these petite freezes from occurring under AHIII Dx11 on my box but not the screen pause.
FYI.......................... .....
:salute
-
hmmmmm I remember skuzzy saying that AH3 could use 3 cores.
Now I gotta test this. I have played the affinity game before, never seemed to matter ultimately, but maybe..................
-
Just to clarify what I did to verify I ran AHIII Dx11 w\ CPU core affinity w\ all 6 cores active then ran AHIII Dx11 w\ CPU core affinity set to use 2 cores then made the in-game comparisons as 1 test cycle.
I did this a total of 4 complete cycles and witnessed the results that I posted on every cycle.
During this test cycle I also witnessed another screen pause occur beside the 1 that I posted on in my last post, this 1 came during test #4 while I was on the runway at A1 during the engine startup routine which lasted approx 2 secs. After exiting out I checked my MSI AB graph and noted that this screen pause occurred just after Windows made a core usage change to run the game (was using Core1 and Core4 prior then switched threads from Core4 to Core2 while still using Core1). This was odd to me as I had never witnessed this occurring since I started monitoring this using MSI AB until I remembered that I had just exited out of AHIII Dx11 when I had all 6 CPU cores active and had made the CPU core affinity setting change to 2 cores active, but I made the affinity change at the startup screen w\o fully exiting the game 1st (I had fully exited the game before I did this on the 3 prior sessions) due to me also noting that while AHIII Dx11 was at this screen the game wouldn't crash when opening Task Manager to set CPU core affinity to the game process (tested this using AHIII Dx9 as well but the game would crash when I tried to open Task Manager w\ the opening screen clipboard up.....solved this by minimizing the game before opening Task Manager. Doing this using AHIII Dx9 I saw no change at all...game ran just as flawless w\ 2 CPU cores as it has w\ all 6 CPU cores) so instead of exiting out fully then restarting AHIII Dx11 I exited to the opening screen then went in & changed the CPU core affinity w\o fully exiting out.
This last screen pause may have been my fault but it also does bring to light that some of these screen pauses just may be due to Windows switching threads across multiple lightly loaded CPU cores.....which I'll admit is really mostly a misnomer as if I've read this correctly Windows OS's are coded to do all this on a preemptive basis so this really happening should be very rare to none.....but I also saw evidence of this actually happening so.................
The whole reasoning for me doing this was to test the theory of consolidating the CPU core usage under AHIII Dx11 to less CPU cores that the actual CPU core usage per core would increase by stopping Windows from parsing game threads across all 6 cores hoping that this would also stop the on die Intel SpeedStep CPU control from potentially downclocking\underpowering the CPU cores due to very low core usage %. IOW's I hoped they would mimic the CPU core usage pattern I've consistently witnessed when running AHIII Dx9 (used 2 CPU cores exclusively w\ very high usage % across both cores), got the 2 core usage pattern but the core usage % was still pretty low relative to core use under AHIII Dx9........
Continuing on....................
:salute
-
As I've been reading a couple of these posts I've been struck by a couple things. My "mini-freezes" seem rare and quick to what at least some others are seeing. Mine seem unpredictable, only show up occasionally, and resolve too quickly for me to react to do anything. If they happen at an inopportune time, I suppose they could cause me to miss a shot, but because I get a bit better performance on DX11, I've been inclined to commonly run DX11 because my mini-freeze issue is pretty minimal.
I have an i3 6100 in my machine, a dual core processor, so if there is a core-swapping issue with cpus with 4 or more cores, my having minimal issue with my dual core processor seems consistent with that theory......
-
As I've been reading a couple of these posts I've been struck by a couple things. My "mini-freezes" seem rare and quick to what at least some others are seeing. Mine seem unpredictable, only show up occasionally, and resolve too quickly for me to react to do anything. If they happen at an inopportune time, I suppose they could cause me to miss a shot, but because I get a bit better performance on DX11, I've been inclined to commonly run DX11 because my mini-freeze issue is pretty minimal.
I have an i3 6100 in my machine, a dual core processor, so if there is a core-swapping issue with cpus with 4 or more cores, my having minimal issue with my dual core processor seems consistent with that theory......
Hi DaddyAce,
Got some info here to interest you on this subject.
I just got done running AHIII Dx11 on my box and setting the CPU core affinity in Windows to run the game starting w\ a single CPU core, then upping the CPU core affinity to add a core each session then snipping the MSI AB graphs of each for comparison.
Please pay particular attention to the GPU frametime graph line on each 1......you'll note the change in the graph line smoothness across each successive CPU core added into the mix....you'll also note some of these graphs will show a single large spike in the graph lines...those represent a single screen pause where the screen motion froze for a sec then resumed motion. The myriad of mini spikes in the GPU frametime graph lines represent the petite screen freezes while the game is running.
What all this data is demonstrating is that a lot of issues we see and blame on the vid card is not the vid card at fault......it is actually the CPU operation that is causing the GPU to react in negative ways.
AHIII whether it is running under Dx9 or Dx11 runs the smoothest\best when it is running on 2-4 CPU cores TOTAL. Any CPU w\ less than 2 cores or more than 4 cores in use show on my box to exhibit the petite freezing issues due to the CPU operation being slowed down\made erratic too much causing the GPU to hesitate thus the petite freezing w\ the exception of AHIII running under Dx9. Hyperthreading will not help w\ this issue at all.....actually I believe it will make it worse (I have hyperthreading disabled on my I7 5820K Haswell-E 6-core CPU) unless you're running a 1-core or 2-core CPU.
From all this I am becoming even more certain that all these issues are arising from the CPU being underutilized due to Dx11 vs Dx9 causing Intel SpeedStep to interfere w\ CPU voltage\clocks settings causing CPU instability . If the CPU loading can be increased under DX11 to get the cores above and stay above the 50%-60% usage mark I believe this will be enough to stop Intel SpeedStep from interfering w\ the CPU voltage\clock speeds in which all this will go away.
Enjoy!
:salute
-
Here's the last graph snippet w\ all CPU cores active................
Enjoy.................
:salute
-
Skuzzy,
Here are 4 .dmp files that I discovered in the AH temp folder that were created yesterday.
Hope these help y'all out.
:salute
-
Update:
I got a hunch again on all this and went into my box's UEFI to look more closely into my CPU's advanced core settings and found the CPU EIST Function setting (this setting is what controls Intel Enhanced Speed Stepping at the CPU level from the UEFI) so I set the UEFI to disable this function in my I7 5820K CPU, saved it, rebooted then checked this thru Gigabyte's SIV......my CPU is showing now to be locked solely into Intel's TurboBoost function w\ CPU consistently clocking between 3900-4003 MHz (this is set in my UEFI's CPU Upgrade setting). So this will not be fully disabled thru the Windows Power Management scheme of High Performance....only at the UEFI\BIOS level.
Went up using AHIII Dx11 using all 6 CPU cores to test..............testing has now confirmed that it was Intel's EIST that was causing the petite freezes while running under Dx11 due to the low CPU core loading. Here is a snippet of MSI AB graph showing a pretty clean GPU frametime graph line now w\ all 6 CPU cores being used and Intel EIST disabled in the UEFI......
However, you will also note that a screen pause was also recorded and when I moved the white synch line over the large GPU frametime spike then traced down to the CPU core usage this showed once again to coincide w\ CPU core usage % to be less than 35% on any active CPU core which is following the same pattern of all other screen pauses that I've captured since I set up the individual CPU cores to be graphed.
I'm gonna run some more tests w\ CPU affinity cut to the optimum CPU core numbers that have shown the AHIII game client to run the best under w\ EIST disabled to see if the screen pausing ceases..........but I don't see this happening unless the CPU core loading goes up enough to keep up w\ a fully optimized GPU at full GPU clock speeds.....and this IMHO can only be achieved thru the game client software OR me making setting changes to try to slow down the GPU to better "synch" w\ the current CPU game loading w\ AHIII Dx11.
IOW's I believe these screen pauses are due to a timing issue created between the CPU\GPU being influenced by the AHIII Dx11 game client and\or other external factors that shows up once the CPU core usage % drops below 35% on all active CPU cores. Again I'm NOT making any claims that the AHIII game client is BROKEN under Dx11 so don't take this there.
What I will suggest is that maybe the AHIII game client could use a little more tweaking to make more use of the CPU cores relative to the current usage model to raise the CPU core usage or loading up some more OR raise the post-processing rendering levels\GPU work load levels as hard coded in the AHIII game client to work the GPU some more to effectively slow it down just enough to "synch" better w\ the current CPU loading when running under Dx11.....but this may not be feasible IF doing this breaks the game client from being able to qualify for VR certification.....which is what I'm kinda suspecting would be the quandry at hand at this time. As for running under Dx9 the game client needs no further enhancing work done to it that I can detect.
Just a hunch.................... ;)
If I may ask, is there any way that I could talk the nice folks at HTC to consider to write into the game client coding the instructions to instruct the OS to assign CPU core affinity so when the game is started up the optimum number of CPU cores to be used will be automatically set up? I know I'm asking for a lot here but I REALLY like how the client performs when the CPU cores being used are limited to 2 total CPU cores and I KNOW that MS ain't gonna go there............
You do realize that Christmas IS just around the corner and Santa would love it as well while he's flying his sled in the game that he has put the insignia of Johnnie Johnson's Spitfire Mk IXe on the sides of it.......maybe w\ a case of a little something, something wet and over 81 proof thrown in to boot................. :pray
:D
Yeah I know this was bad but I just HAD to try................
:salute
-
Here's a graph w\ AHIII Dx11 running on CPU core affinity of 2 CPU cores w\ EIST disabled along w\ Hyperthreading disabled in the UEFI:
As I suspected, all else was eliminated....except the screen pause. When I ran the timeline over the GPU frametime spike then traced it down to the 2 CPU cores the core usage on Core1 was down to 25%, Core2 was down to 14% when the pause occurred.
But other than this, the game performance was just spectacular to behold.............and the graph lines clearly give a picture of this..........
FYI.......................... .....
:salute
PS--Skuzzy, do y'all have all y'all's computers @ HTC set up in the BIOS\UEFI w\ Intel SpeedStep disabled? If y'all do then this would most likely be the reason why y'all haven't been able to duplicate all the petite freezes running the Dx11 version. As for the screen pauses I can't say but to ask: what is the CPU core usage load % on y'all's boxes when running AHIII Dx11 w\ a VR headset attached vs w\o a VR headset attached and is it consistently staying above the 35% threshold that I've identified on my box from my testing? If if is then this may also be the reason why y'all can't duplicate these screen pauses as well.....
Just laying out a thought of mine for consideration................ ........
:salute
-
Hi Pudgie,
Reads like you're making progress tracking down clues......If I'm following you correctly, in summary, you were getting nearly constant mini-freezes, but got those ironed out by turning off cores, etc.
Now that looking at your graphs have me tuned in to the utility of "Frametime", I've set up my AB to include frame time in my next set. I'm guessing my frametime graph, produced by running AH3 DX11 on my i3 dual core will look similar to the one you just put up....that pretty flat with just the occasional spike. I'l try to run a graph or too later today when I fly....meanwhile should spend some time in RL activities.....
:salute
-
I have tried everything Pudgie is doing now. In shorts tests the "pause-and-play" petit freezes cleared up (in my case) but after extended play would always return.
My conclusion is that instead of trying to correct our systems to fix the problem, we need to record and film, and then post reports. Even if we find something like the speed-step as a possible cure it is not a fix, because there are many, many users that could never find the setting to even change it!
I tried the CPU affinity change and unless there is some mysterious combination of cores that will work I still get petit freeze. I applaud Pudgie for trying though.
-
Hi Pudgie,
Reads like you're making progress tracking down clues......If I'm following you correctly, in summary, you were getting nearly constant mini-freezes, but got those ironed out by turning off cores, etc.
Now that looking at your graphs have me tuned in to the utility of "Frametime", I've set up my AB to include frame time in my next set. I'm guessing my frametime graph, produced by running AH3 DX11 on my i3 dual core will look similar to the one you just put up....that pretty flat with just the occasional spike. I'l try to run a graph or too later today when I fly....meanwhile should spend some time in RL activities.....
:salute
Hi DaddyAce,
The main issue that I found to create the mini-freezes when running AHIII Dx11 is actually Intel's EIST CPU power\frequency control kicking in causing the CPU to cut power\core frequency and operate erratically which was affecting the GPU operation due to the light CPU core loading derived from running AHIII under Dx11 API. I also found out that this can't be reliably shut down thru the Windows Power Management scheme....only thru the UEFI\BIOS. Once I disabled this in the UEFI it doesn't matter about CPU core affinity being in the mix concerning the mini-freezes.....all was showing to create a clean GPU frametime graph line which indicates that the CPU and GPU are working together now in near perfect synch.
But the CPU core affinity really does matter to the AHIII game client as the AHII game client, according to HTC, was written to be run (or read as optimized) on 2 CPU cores and this was brought over to the new AHIII client initially. There was some discussion during the Beta that Hitech was thinking about upping this to 3 CPU cores for AHIII but I haven't heard anything since to solidify this. My initial testing by hard setting the CPU core affinity showed to improve on the GPU frametiming until I set the affinity on 1 CPU core or in excess of 4 CPU cores in which the mini-freezes reappeared. But an exchange of info from reading MADe's postings in another thread got me thinking to recheck the CPU core settings in my box's UEFI which lead to the discovery that I just typed about prior to this post.
My testing the AHIII game client running on the forced 2 CPU cores shows why this game client really needs to have CPU core affinity assignment written into it's coding IMHO nowadays to reflect the advent of it being run on platforms using multi-core CPU's in excess of the optimum CPU core count on which it was written to perform with. The less thread parsing across multiple CPU cores that Windows has to do the better Windows performs these functions thus the better the game shows to run.......but that is gonna be up to Hitech to decide if its worth the coding effort to incorporate it into the client software......thanks in no small part to Microsoft not providing provisions for this to be set thru the OS per app\game in a user friendly, permanent fashion so you don't have to redo this every time you start the game up. The perfect place to had provided CPU core affinity setting access thru the OS is thru the app\game shortcut icon Properties, Compatibilities tab..........
And your other point you've made is well taken, sir!
Signing off for a while........................ ............
:aok
:salute
-
I have tried everything Pudgie is doing now. In shorts tests the "pause-and-play" petit freezes cleared up (in my case) but after extended play would always return.
My conclusion is that instead of trying to correct our systems to fix the problem, we need to record and film, and then post reports. Even if we find something like the speed-step as a possible cure it is not a fix, because there are many, many users that could never find the setting to even change it!
I tried the CPU affinity change and unless there is some mysterious combination of cores that will work I still get petit freeze. I applaud Pudgie for trying though.
Thanks for the flowers Chalenge!
I get what you're posting here on all points and am certainly not advocating anyone else to follow suit just because I'm doing it.
What I'm hoping to accomplish is not to fix the issues w\ this game on my end per se, but to highlight these issues to hopefully assist HTC to identify operational realms from the good work that they've done so far w\ this new AH game client that can unintentionally cross over into areas of interoperability to ampify issues that sometimes may not be so obvious at the onset due to a single reported symptom that can point to multiple causes of said symptom....like remembering where the Intel CPU load threshold is that will invoke something like Intel's EIST to work against your client running smoothly then working your client to ensure that this line isn't crossed while your client is running on other's systems to remove it as a potential cause......because the results of my testing does expose it to be a potential cause of these symptoms.
So I will ask of you, have you tried all this on your box w\ SLI disabled using only 1 vid card running? I don't know as you've never posted to this effect (you have posted that you do run AH on SLI'd GTX 980's that I know even w\ Nvidia doing a LOT of work w\ their drivers to cure the GPU frametiming issues that occur from SLI'd GPU's which can create these same petite freezes due to interleaving) and I'm running a single vid card and from my testing since I've made these changes I've never witnessed the petite freezes showing up again...only the occasional screen pause. I also do realize that my vid card is an AMD R9 Fury X vid card and due to it's architectural design parameters\driver stack tuning may benefit more from this kind of work than your GTX 980's might............
Just asking...............
I'm not saying that you have to or even that you should just because I asked but I am curious of this for my own knowledge\understanding if nothing else as I do not have any intention of SLI\Crossfire usage on my boxes so I'll never really know this for myself unless someone else posts their results to this effect.
Anyway have a good holidays and I'm gonna give this a rest for a while.
:salute
-
Yes, I thought it could possibly be the SLI method, so I tried five different modes and still get the pause-and-play hesitations. You seem to be saying that petit-freeze and screen-pause are two different things, but they are the same thing to me.
What caused me to give up trying to configure the game to run without this problem was when I ran the game on a top end workstation system and still got the same events. The game runs great otherwise and looks amazing.
-
Windows 10 X64 Pro Edition.
Petit-Freeze / 1/2 sec. Screen Pause
Seems to be tied to Windows Audio, Windows events, AH3 audio. Not sure how to change the priority of that, or to allow for more/less buffer.
-
Pudgie, Here is some more AB data I collected last night as promised. Running DX 11, graphics settings full on. You'll see a few frame time spikes, which correspond with CPU usage spikes. In the event Skuzzy, Pudgie, or any of you other guys who understand this a lot more than I do, happen to find this useful, I do have a corresponding film file I can get to you too if you want it.
Cheers!
:salute
-
Yes, I thought it could possibly be the SLI method, so I tried five different modes and still get the pause-and-play hesitations. You seem to be saying that petit-freeze and screen-pause are two different things, but they are the same thing to me.
What caused me to give up trying to configure the game to run without this problem was when I ran the game on a top end workstation system and still got the same events. The game runs great otherwise and looks amazing.
Hi Chalenge,
From all my testing I believe that they all are a result of the lower than normal CPU\GPU core loading due to the AHIII game client running under Dx11...in this aspect they are all caused by the same. As for the petite freezing I also was able to isolate this particular aspect to be more affected by the advent of Intel's CEIST being active (a symptom of the cause), which is also activated by low CPU core loading, but when I used CPU core affinity to reduce the amount of CPU cores available to be used w\ the game under Dx11 w\ CEIST enabled this also raised the CPU core loading on the CPU cores being used enough to stop CEIST from throttling the CPU core power\frequency which stopped the GPU micro hesitations from causing the petite freezes on my box as well (very noticeable thru the GPU frametiming graph line in MSI Afterburner as well as visually while in game). If I used 1 CPU core or more than 4 CPU cores the petite freezes came back but for different reasons but I could still see a slight difference in the GPU frametime graph line between 2 CPU cores being used vs 3 or 4 w\ the GPU frametime line being the cleanest when 2 CPU cores were being used.....which lines up w\ HTC's statement of the client being written to use 2 CPU cores. This tells me that the game threading is optimized on 2 highly loaded CPU cores and using more than 2 CPU cores starts to introduce unwanted CPU latency due to the OS wasting time parsing game threads across all these CPU cores which shows up at the GPU thru the frametime graph line. This testing has shown me the need for the AHIII game client to have CPU core affinity written into it to maintain game stability across modern platforms as CPU core counts are only gonna grow...........
But neither method has gotten the CPU core usage up enough under Dx11 to stop the screen pausing as from all my testing under the methods at my disposal I haven't recorded a screen pause occurring when the CPU core usage %, regardless of the number of CPU cores being used from 2 cores up to 6 (I have Hyperthreading disabled on my I7 5820K CPU), if the CPU core usage stays above 35% on the highest loaded CPU core while the game is running.....only when the CPU core usage drops below this mark is when a screen pause has occurred. This is the only data that I have found to be consistent w\ this happening on my box to date. But until I can get the AHIII game client running under Dx11 to consistently maintain CPU core loading to keep it consistently above this 35% mark to then prove that this IS the main issue can I make the call. So far I cannot make this happen on my end unless I reduce the CPU core usage to 1 CPU core then I've gotten everything else negative to start showing back up due to 1 CPU core w\o Hyperthreading enabled ain't gonna cut it running AHIII game client. Using 2 CPU cores the best I have gotten is 60%-70% but the game has to be very busy along w\ a high texture count map loaded as well or it won't stay there and will drop back below this mark. Haven't witnessed this occurring as soon as it lowers below 35%....have seen the CPU core usage be as low as 9% when a screen pause occurred but 34% is the highest recorded CPU core usage I've noted when a screen pause did occur thus I use 35% as the threshold for now.....................
So in short I agree w\ you on this but I believe that the true source is due to the lower than normal CPU core loading derived from the AHIII game client, which was optimized to run under Dx9, being ported to run under Dx11 since the VR coding was added to the client as when I've compared the recorded CPU AND GPU core loading of the AHIII game client being run on both Dx API's the difference is very large and noticeable in favor of Dx9 showing to load the CPU\GPU FAR more than Dx11 does thus I also believe this is why the AHIII client run under Dx9 runs w\o all these petite freezes\screen pauses showing up on my box.
All other items that we've all discovered, brought to the table are but symptoms of the central issue as this low CPU core loading can affect ALL the other devices operation as well and cause a domino effect.....not that the other devices don't need to be looked into. Since going thru all this I've found quite a medley of issues concerning my broadband equipment on my end that didn't help w\ the situation either so I've got some good out of doing all this on my end as well.
This is where I'm coming down on all this after the work I've expended into diagnosing this problem on my end.
Other than all this the game does run excellent on my box as well whether under Dx11 or Dx9.
Since shutting down CEIST in my UEFI all I see happening now is the screen pausing every once in a while...........
So as you I'm pretty much at my end of all this and will be playing AHIII under Dx9 going forward as I don't use a VR headset so am not wetted to using Dx11 exclusively but I really want to run the game under Dx11 due to the graphics performance that I've seen w\ my Fury X running under Dx11 vs Dx9 but the screen pausing gets very old and does interrupt game play.
But from discovering what I have noted concerning my set up I will also be setting the CPU core affinity to 2 CPU cores on my box when I do play going forward........
:salute
-
Pudgie, Here is some more AB data I collected last night as promised. Running DX 11, graphics settings full on. You'll see a few frame time spikes, which correspond with CPU usage spikes. In the event Skuzzy, Pudgie, or any of you other guys who understand this a lot more than I do, happen to find this useful, I do have a corresponding film file I can get to you too if you want it.
Cheers!
:salute
Hi DaddyAce,
From looking at your snip of your MSI AB graph I can see 2 instances of your box going thru a screen pause where the screen graphics just stopped for a sec then resumed motion. Note the 1 GPU frametime spike to the left and the 1 in the center that also lines up w\ the GPU clock speed drop as well as the GPU FPS drop which something caused the GPU to hesitate then resume. Also note following this down to the CPU core usage lines, especially Core1 which is the heaviest used CPU core on your box (just so you know Core 1 and Core 3 are your CPU's 2 physical CPU cores....Core2 and Core4 are 2 logical CPU cores created by hyperthreading being enabled in your mobo UEFI\BIOS....this why your Intel I3-6100 2-core CPU is showing 4 CPU cores in this graph so the OS thinks you have a 4-core CPU and will try to parse game threads across them all when it is actually using the CPU core wait time from running 1 thread on 1 of your CPU's physical cores that is waiting on something to finish executing this thread to start work on another thread waiting in the queue to be run...so in short parsing 2 active threads across a single CPU physical core....this is hyperthreading and how it works) you should see to the left a large CPU usage down spike in the graph line and in the center you can clearly see the CPU usage dropping off and see the CPU usage down spike that is clearly below the 35% usage line gauging by the timeline just to the left of the center spike showing the CPU usage % down to 42% from a high of better than 75% then going back up after the screen pause.
Now the 1 that I see on the left side of your graph I have never witnessed a screen pause happening when the CPU usage % was that high so that 1 has caught my interest. All the ones that I have witnessed and captured on my end were represented by the 1 I see in the center of your graph.
Otherwise your components are showing to be working well w\ AHIII running under Dx11. If you're seeing any of the petite freezes you might look into disabling the Intel CEIST in your mobo UEFI\BIOS if you haven't done so already and see if they stop occurring for you. You can also look into disabling Hyperthreading in your UEFI\BIOS and then check to see if they go away as well.
That is if you've a mind to try all this......................... ..
Hope this helps you out.
:salute
PS---The screen pausing from my testing is showing to be created from issues at the CPU level and not at the GPU itself but shows to affect the GPU operation as noted thru the GPU frametiming graph line. I have gone thru at least 7 Crimson driver version upgrades w\ none of them showing to have any part in creating this issue or arresting this issue to date.....and so I don't see the Nvidia graphics drivers as a potential source of issue from looking at your graph as well. Forgot to put this in my posting earlier.........
:salute
-
Hi Pudgie,
Thanks much for your analysis; you're a heck of a resource to have here! :aok
I enjoy learning about this stuff, which is part of the reason I built this machine. I was wondering about the 4 cpu graphs and figured they must have represented the Cores and threads, but didn't know the specifics, thank you for explaining that!
Yes, those spikes corresponded with brief screen freezes. I'll likely pass this along to my puter engineer son and get his take on what i'd be getting into if I mess with the UEFI\BIOS, but I imagine it's not too risky. I'm familiar enough with the bios to know there's a return to default setting as well as a physical jumper to rest the bios if I really get into deep doo doo. I also finally earlier today sent your question about his comment about serial processing of internet data. Right now he's in Malaysia, so on quite a different schedule, and likely also busy with his web site with all the sale stuff, so I'll get back to you if he get's me a reply....and I'll also keep you posted if I give it a try; but my sense is hey why not, it's always fun to learn, with the caveat that it would not be a good timing for me to lose a lot of time right now if I screw something up too badly.
:salute
-
Is there a fix for the cloud shadow flickering? Other than shutting off shadows? Noticed it real bad in DX9 last night, don't recall seeing it before though. Switched to DX11 and was far less pronounced, but I get screen freezes with 11. For now I will just run 9 without shadows, but was wondering if anyone might have a quick fix. :salute
-
..... If you're seeing any of the petite freezes you might look into disabling the Intel CEIST in your mobo UEFI\BIOS if you haven't done so already and see if they stop occurring for you. You can also look into disabling Hyperthreading in your UEFI\BIOS and then check to see if they go away as well......
I tried this, was drop dead simple to turn off/on in Bios, but didn't seem to affect my petite freezes....but not a big deal for me becasue they are quick and don't happen often. But thanks for tip, worth a try Pudgie!
Also, heard from my son regarding your question about his "serial processing" comment, his main was that when running AH3 online "....there is more information. The location and speed of enemy plans, and especially their bullets. And everything needs to stay in sync between you, the server, and every other player, so that adds extra demands."
:salute
-
Turn OFF SuperFetch.
And keep an eye on it. I turned mine off back in the beginning (AH2 days) and some update (probably Anniversary) turned it back on.
You may still see some hiccups when you make graphic detail changes, and other clipboard operations, but they will be significantly reduced.
-
Turn OFF SuperFetch.
And keep an eye on it. I turned mine off back in the beginning (AH2 days) and some update (probably Anniversary) turned it back on.
You may still see some hiccups when you make graphic detail changes, and other clipboard operations, but they will be significantly reduced.
Did not help in my case.
-
I note that every stutter that I have is accompanied by a spike be that small or large in the Net status window, the top graph. Its always worse near water, and manic near the fleets for some reason, even whilst FPS says between 46 - 60.
-
I have tried everything Pudgie is doing now. In shorts tests the "pause-and-play" petit freezes cleared up (in my case) but after extended play would always return.
My conclusion is that instead of trying to correct our systems to fix the problem, we need to record and film, and then post reports.
<snip>
Yes, please!
-
I note that every stutter that I have is accompanied by a spike be that small or large in the Net status window, the top graph. Its always worse near water, and manic near the fleets for some reason, even whilst FPS says between 46 - 60.
A "Variance" spike would be normal and not indicative of the situation but a result of the situation.
-
Just tried offline and no stutters near fleets but still some minor freezes as I assume skins and planes load? It's an odd one and I don't envy your search skuzzy. :cheers:
-
Skuzzy, is there a recording program we can run in the background to track all that is going on with our machines. We used to use a device called a glitch catcher when I worked Instrumentation on the Trans-Alaska Pipeline trying to track down spurious signals and other unknowns. Could the Task Manager logs be set up to record everything? Just some thoughts. :joystick:
-
Here are 2 AH films of me flying just now running AHIII under Dx11, 1 film using all 6 CPU cores, 1 film using 2 CPU cores.
Enjoy!
:salute
-
Turn OFF SuperFetch.......
Tried it but didn't seem to help.
:salute
-
Yeah, I recorded five resupp sorties tonight that were filled with petit freeze, and then one flawless sortie up to 37k to catch perk Mosquitos. I'll have to convert them and get them on YouTube for HTC to see them.
-
Here are 2 AH films of me flying just now running AHIII under Dx11, 1 film using all 6 CPU cores, 1 film using 2 CPU cores.
Enjoy!
:salute
Ok,.if the films do not show the long pause, or the stutters (they usually do not), we also need a corresponding capture (Fraps, or whatever your favorite is) as it will capture the pause/stutters and we can them correlate that to the film.
Yeah, I recorded five resupp sorties tonight that were filled with petit freeze, and then one flawless sortie up to 37k to catch perk Mosquitos. I'll have to convert them and get them on YouTube for HTC to see them.
Converting them to Youtube loses all the information we embed in the films and does us no good. We need the native film and the captured one.
-
I meant the recording I made along with the AHF files.
-
Ok,.if the films do not show the long pause, or the stutters (they usually do not), we also need a corresponding capture (Fraps, or whatever your favorite is) as it will capture the pause/stutters and we can them correlate that to the film.
Converting them to Youtube loses all the information we embed in the films and does us no good. We need the native film and the captured one.
Ok, so what you're saying is that when we do this we need to have the game record AND have some other software such as Fraps also running and recording the same patch of gameplay so that both can be viewed in synch to assist y'all, correct?
Where do I get this Fraps?
:salute
-
Ok, so what you're saying is that when we do this we need to have the game record AND have some other software such as Fraps also running and recording the same patch of gameplay so that both can be viewed in synch to assist y'all, correct?
Where do I get this Fraps?
:salute
FRAPS (http://www.fraps.com/download.php)
Coogan
-
FRAPS (http://www.fraps.com/download.php)
Coogan
Thanks!
:salute
-
Thanks!
:salute
Not a problem.. :cheers:
Coogan
-
OBS Studios (https://github.com/jp9000/obs-studio/releases/download/0.16.6/OBS-Studio-0.16.6-Full-Installer.exe) has a small profile and runs well in the background too.
-
OBS Studios (https://github.com/jp9000/obs-studio/releases/download/0.16.6/OBS-Studio-0.16.6-Full-Installer.exe) has a small profile and runs well in the background too.
That's what I use for streaming. Very good program.
Coogan
-
ACTION can be found here: https://mirillis.com/en/products/action.html (https://mirillis.com/en/products/action.html)
If you have Nvidia card, Nvidia Shadowplay is part of the Geforce Experience. http://www.geforce.com/geforce-experience/download (http://www.geforce.com/geforce-experience/download)
-
Update:
D'ld AHIII Patch 12 and went up a few times from A66 to A67 this evening using the Dx11 version. Here's a couple of snippets of MSI AB graphs of my box's CPU core usage, 1 snippet is using 2 CPU cores, the other is using all 6 CPU cores.
So far I haven't had 1 hiccup anywhere....game has ran flawless so far on my box.................
Very promising.................... ...............
Continuing testing..................
:salute
-
Update:
Here's another snippet of MSI AB graph of my box running AHIII Patch 12 Dx11 w\ all 6 CPU cores active and now w\ Intel CEIST enabled provided below....note the CPU core usage.
Game action from A66 to A75.....game ran flawless.
Very promising indeed.................
Continuing testing..............
:salute
-
With the latest release (12) the periodic stutters have stopped, however the Vox stutters continue. Also noted the waves appear to be twitching sporadically when flying over them. I was in CraterMA using DX11.
-
Petit freeze has disappeared, hopefully forever.
The water on the other hand . . . as stated, but it seems like an incomplete animation cycle. The cloud flicker has returned.
-
The water animation anomaly is just temporary. It was a quick fix to give us time to provide a more paermanent solution. We are aware of the cloud flicker.
-
Zero petite freezes for me with DX11 last night as well.
Water "twitch" video uploaded in the bugs section....
-
My petite freezes seem to have completely gone away as well, although roughly simultaneously with the latest game update I upgraded to a new 1440p monitor. Am consistently running the DX 11 version with 0 issues now.
-
I spoke too soon about my freezes going away...., although mine are only a minor annoyance. But in case this provides a useful clue I'm wondering if some of these issues are map specific. For example I tried 3 times to get into Pearl Harbor this evening, all 3 times there seemed to be some strange flashy bright lines outside the tower, and all 3 times AH3 crashed before I could finish reading the opening message about the event. Twice in DX11 version, and once in DX9 version. I tried rebooting machine, no difference. Flew in the Melee arena before and after without difficulty, so the only thing that seemed different to me was the map. Am attaching a Dxdiag file in case it is useful. I tried to attach the dump files, but the site seemed to reject the upload. Hope this helps!
:salute
-
Mine too, although there may be something going on with my system. I'm going to do a general tear-down and rebuild tomorrow. It's time for new thermal grease, and replacement fans.
A few hours ago I got a kernel-power lockup and forced sleep mode, which was interesting. The dmp file indicated a fault in USBHUB3.sys (above my paygrade).
-
OK, don't know if this has a bearing but after the patch today loads of freezes, checked my task manager, stopped the Adobe update service, tab back into game, not one freeze! Now, hopefully it is the patch that has sorted it and it was just settling down, but I have stopped Adobe update service from starting so i will investigate further and report back.
-
sorry worth mentioning after patch I manually cleared the users\appdata\local\temp so that might have been why my stutters happened as adobe tried to update but I stopped the service and not one freeze as I said.
-
I usually open the CC update app and check for updates before I log in. Update. Then I start up Razer Cortex and close all those background apps. I also have Spybot Anti-Beacon, which does an excellent job of preventing telemetry.
I don't know if this latest update got rid of my petit freeze (I thought it was gone before, but then it returned), but I did discover that a webcam was causing an issue with the USBHUB3.sys (and possibly the Kernel also). The steps I took were to remove my sound card (because of a possible issue between it and Nvidia GPUs on my motherboard), install a USB sound card (Sound Blaster Surround 5.1 USB), remove a Microsoft webcam (Windows 10 hates webcams, even their own), replaced all internal cooling fans, reseated the processor, replaced all SATA cables, and moved AH3 to an SSD (disk benchmarking showed the drive I was using may have had write issues).
Tonight my system is running 6C cooler with zero petit freezes.
-
...... The steps I took were to remove my sound card (because of a possible issue between it and Nvidia GPUs on my motherboard), install a USB sound card (Sound Blaster Surround 5.1 USB), remove a Microsoft webcam (Windows 10 hates webcams, even their own), replaced all internal cooling fans, reseated the processor, replaced all SATA cables, and moved AH3 to an SSD (disk benchmarking showed the drive I was using may have had write issues).
Tonight my system is running 6C cooler with zero petit freezes.
Wow! Now that's dedication! :aok
-
Wow! Now that's dedication! :aok
Hi DaddyAce,
That's how us geeks roll......................... ............
:cheers:
-
I usually open the CC update app and check for updates before I log in. Update. Then I start up Razer Cortex and close all those background apps. I also have Spybot Anti-Beacon, which does an excellent job of preventing telemetry.
I don't know if this latest update got rid of my petit freeze (I thought it was gone before, but then it returned), but I did discover that a webcam was causing an issue with the USBHUB3.sys (and possibly the Kernel also). The steps I took were to remove my sound card (because of a possible issue between it and Nvidia GPUs on my motherboard), install a USB sound card (Sound Blaster Surround 5.1 USB), remove a Microsoft webcam (Windows 10 hates webcams, even their own), replaced all internal cooling fans, reseated the processor, replaced all SATA cables, and moved AH3 to an SSD (disk benchmarking showed the drive I was using may have had write issues).
Tonight my system is running 6C cooler with zero petit freezes.
Was it this one?
http://us.creative.com/p/sound-cards/sound-blaster-omni-surround-5-1
:salute
-
This one:
http://us.creative.com/p/sound-cards/sound-blaster-x-fi-surround-5-1-pro
Skuzzy had mentioned that they do 3D positioning on the video card, and some other users had said they get sound from vehicles spot on even when not using a 3D positioning card. So, either one of these will work from what I can tell. The one I pointed to does have lower SNR (more noise), so something to be aware of. The audio sounds identical to the ZxR and I think I have fairly discerning ears.
-
Hi DaddyAce,
That's how us geeks roll......................... ............
:cheers:
Hi Pudg,
Oh yes, I get it, with a son who is a puter engineer, and me more of a Bio & water sciences geek. Geeks rule! :cheers:
-
<KNOCK ON WOOD>
I haven't noticed any stutters or micro freezes since last update. However, during FSO (or maybe in the MA) I noticed very bad shadow flashes and texture skipping (best way I can explain it). Especially in external view, it looks like the plane texture like jumps or something. The cloud shadows kind of warp too. They like, flicker.
-
In FSO last night I saw the flashes too. I don't know if it's something to do with the sunlight thru the high clouds or what.
I had no micro stutters but did get a hard lock requiring a reset.
I flew for a while afterwards in the main arena without issue.
Sent from my XT1585 using Tapatalk
-
If you turn shadows off the flickers go away. I have been able to minimize their appearance by minimizing processes, turning AV off, and overclocking the GPU and VRAM. That does not fix it, but minimizes the flicker.
-
If you turn shadows off the flickers go away. I have been able to minimize their appearance by minimizing processes, turning AV off, and overclocking the GPU and VRAM. That does not fix it, but minimizes the flicker.
It seems the flickery flashes, in my experience, seem to be terrain specific. I've seen them on certain terrains or in certain areas of terrains and not others. I've flown over areas that were not flashing but could see a set of hills in a certain direction flashing like crazy. I seem to recall each time it's happened there were multiple cloud layers in the area and it was middle day. Not late or early day, dawn or dusk.
I already overclock my 6950 which gives a solid FR generally. This isn't a problem as it happens for example in last night's FSO I was just flying straight and level, a little after 1 in the afternoon, away from a lower cloud patch with the sun at my 4:00 high diffused thru a high cloud layer. Nothing going on. FR fine. Stuff just flashes. I was over water but I don't think the water was flashing, just my plane and the cockpit.
I haven't looked at what video I had from last night but I'm sure I have other examples of the flashyflashy.
It's SOP before flying that I turn off all crap unrelated to the game that I can. Every clock cycle counts!
Of course I just realized after writing this is probably unrelated to the micro stutter and lockup problem. Don't let me derail the thread.
Sent from my XT1585 using Tapatalk
-
This one:
http://us.creative.com/p/sound-cards/sound-blaster-x-fi-surround-5-1-pro
Skuzzy had mentioned that they do 3D positioning on the video card, and some other users had said they get sound from vehicles spot on even when not using a 3D positioning card. So, either one of these will work from what I can tell. The one I pointed to does have lower SNR (more noise), so something to be aware of. The audio sounds identical to the ZxR and I think I have fairly discerning ears.
Hi Chalenge,
Didn't sink in until now..........
So FMOD is actually processing 3D positional sound at the software level. Good to know.
Before I finally went on and pulled the trigger on the X7 I was also looking hard at the Omni myself but I just didn't think that the USB clusters on my mobo could provide enough power to drive it like I wanted, especially the 600ohm headphone amp that is in it.
In hindsight I coulda used either a powered USB hub or a USB\PCI-E add-in card (like I'm doing now w\ my CH HOTAS) w\ aux 12v power to drive it, but it's moot now cause I got ole Big Daddy X7 handling it now.
Glad you got it sorted out.
:salute
-
If its been mentioned, sorry.
Graphics options> terrain detail slider
I have been running it maxed. When in low to ground, with a side look at trees, I got little hitches. I moved that back to about 75%-80%. No more hitching and when at alt since trees not rendered all the scintillating stop around towns and trees.......
Terrain detail no likey maxxxxxed...........
fyi
:rock
-
Hi Chalenge,
Didn't sink in until now..........
So FMOD is actually processing 3D positional sound at the software level. Good to know.
Before I finally went on and pulled the trigger on the X7 I was also looking hard at the Omni myself but I just didn't think that the USB clusters on my mobo could provide enough power to drive it like I wanted, especially the 600ohm headphone amp that is in it.
In hindsight I coulda used either a powered USB hub or a USB\PCI-E add-in card (like I'm doing now w\ my CH HOTAS) w\ aux 12v power to drive it, but it's moot now cause I got ole Big Daddy X7 handling it now.
Glad you got it sorted out.
:salute
I'm not sure it has anything to do with FMOD, and won't until someone at HTC comments about it.
-
Hi All,
So far, since I went into the UEFI, reset CEIST & TB back to Auto then went into Windows Power plan, reset the plan from High Performance back to Balanced (which enables Windows to control CPU power management) then went into the advanced Balanced settings and set the processor power minimum setting from the default of 5% to 75% (so when the CPU sees low CPU loads Windows will limit the CPU power cut to 25% of 100% instead of 95% of 100% when CEIST lowers the CPU power\clock speeds due to low CPU loading....used to use this setup back in my Intel C2D E8600 days running MS Vista......). This will help the CPU to clock back up on demand under load w\o stumbling.......and the install of AMD Crimson ReLive 16.12.1 drivers which brought AMD's new WattMan GPU clock\power control for PowerTune 2.0 to use instead of AMD's outdated OverDrive (which made a big improvement w\ the Fury X's performance), as well as some FreeSynch improvements...........
To date I haven't witnessed a single screen pause\freeze or petite stutter\freeze on my box since I did all this late Thursday evening. FR has been very steady maintaining in the 78-80 FPS range and game play has been beautiful. MSI graphs show a near perfectly clean GPU frametiming graph line................
Now the only things I see are the occasional Internet warp\stutter as my connection at hop #4 but especially at hops #5 & #6 experience near 100% packet loss most of the time as measured using PingPlotter (somewhere between Denver, CO and Dallas, TX.......must be at a transition point from CenturyLink's system to another) but the ping times are never over 100ms regardless so I'm being rerouted causing minor streaming issues.
Finally believe this is behind me now.
:aok
Due to the timing of these changes I don't have a clear idea of which 1 really made the difference (I made the changes to the UEFI and Windows 1st but a few hours later d'ld the new AMD Crimson drivers and installed them after checking out the tech sites in between game testing sessions (I do this regularly as well as check the AH BBS) and read up on the new changes at WCCFtech that were packaged w\ the new Crimson 16.12.1 drivers. I didn't witness any screen pauses\freezes or petite freezes after making the 1st change but I hadn't put enough testing time before making the driver change to effectively state so I'm attributing my success at this time to both changes.
AMD's new Radeon WattMan is a big deal for older Radeon GCN GPU's to provide much better, finer grained GPU power\clock speed control over OverDrive which isn't NEAR as refined & is somewhat responsible for Radeon GPU temps getting out of hand in the past unless you used a 3rd party software to make up for some of it's shortcomings. I'm using WattMan in full AMD default settings (auto mode) w\o any assistance from Afterburner (AB vers 4.2 can't hook into WattMan...) and it's working perfectly w\ my Fury X running AHIII under Dx11 maintaining GPU clock speeds constant at full 1050MHz w\ GPU max temps in the 62*C-65*C range at fan speeds between 1024-1204 RPM's on the AIO.....right in the sweet spot for AMD's PowerTune 2.0 to maintain at\near full power to the GPU (GPU TDP is 75*C) so this Fury X is powering thru the game easily now.
So in conclusion this showed that the screen pausing was being caused by issues on my end that were being exposed by the AHIII game client operation after the VR coding was included to the game client Dx11 port.
Now I'm digging into other venues to explore full CPU optimization efforts w\ AHIII........................ ..
So far I have learned some pretty neat stuff on how all this works together and some "tweaks" that show to be promising w\ the AHIII game client running on a Windows OS w\ a multi-core CPU..................
All geek stuff........................ ..................
:salute
-
Five days stutter free, and then they returned on SFMA, and now NDisles.
-
Hoping not to jinx myself here, but I have been stutter-free as well. Have flown high, low, into airfields with a lot of activity and ground fire, into engagements with multiple aircraft both friendly and enemy with different skins, flew FSO last night, etc. Has been good. I think I may have notived one last week quickly when someone keyed up on vox. But other than that, all is well.
Just out of curiosity, what was changed to get rid of the micro-stutter? What was the issue causing it?
-
I think in my case it was caused by the Windows 10 update that came through about the same time. I discovered that the majority of USB ports had returned to the power-down setting "Allow the computer to turn off this device to save power." Also, the optional settings of Anti-Beacon had been unblocked, so I reset them to blocked.
Even after doing that I find that the scheduled tasks of Office 15 and Office 16 are unblocked, which is odd because I use neither one.
-
I've been petite freeze free for 3 days but haven't changed a thing. :headscratch:
-
Seeing petite freezes on DX9, not so much on DX11. (Which is opposite of what I have seen in the past.) :headscratch:
-
OK, the time that the stutters happen for me are directly related to how close to a CV I am, if I am within a 10 mile radius the game is unplayable, with a 60FPS, outside the CV radius the game is fine. Not sure if it is the same if the CV is lit I will test.
-
OK, the time that the stutters happen for me are directly related to how close to a CV I am, if I am within a 10 mile radius the game is unplayable, with a 60FPS, outside the CV radius the game is fine. Not sure if it is the same if the CV is lit I will test.
I have the same problem around CVs and the stutters also appear randomly at other areas like inland bases (such as the one I posted in this thread (http://bbs.hitechcreations.com/smf/index.php/topic,383847.0.html)) but it is worse around CVs.
-
OK after testing, flying off a CV that has taken no damage, there are no stutters, getting near a CV fleet that has been damaged or the CV has been sunk I get the stutters.
-
Petite Freeze is back, but this time all of the usual suspects are not a factor.
-
Update:
All was good until I switched vid card drivers (Crimson 16.12.1-------->Crimson 16.12.2) to get fixes for ReLive installed.
Was playing last night and suddenly I got the std .5 sec screen pause then resume issue again.........never saw this again after installing the 16.12.1 drivers until now.
From looking at the Radeon WattMan GPU graphs I saw that the GPU activity% line was cycling back and forth between 0% to 100% activity w\ all other graph lines being straight but my MSI AB GPU usage% graph line didn't show any of this...........until I remembered that I had set MSI AB to use unified GPU usage monitoring (this cuts an average of the real time GPU usage%.....gives cleaner graph lines).
So I reset this in MSI AB then restarted MSI AB for it to take effect then ran AHIII Dx11 again, captured another screen freeze in the process then looked at the graph and now the cause is clear to see......the AMD driver is allowing the GPU to stop being used (but not stop running as the GPU clocks never slow down).....most likely due to the shaders doing most of the graphics rendering\AA work so the GPU activity will go to 0% until the GPU is needed to do some work, which is fine as long as the graphics frame buffer has enough finished frames left to flip to allow this GPU activity to get started back up and going to provide more frames before the last frame is displayed.
But this doesn't always happen in time...................so the screen will pause until the frames are provided in sequence again to be displayed....or lock down if the GPU never starts back up.
This appears to be a timing issue created within the AMD driver stack.....guessing this probably has something to do w\ power saving.
Gonna go into MSI AB and check the box to disable ULPS in AMD driver and see if this stops then (Fiji GPU's support ULPS).....................
Here is a graph that I ran thru MS Paint to highlight what I'm talking bout running AHIII Dx11 provided below.
Here is another graph that I ran running AHIII Dx9 for comparison........you can see that the GPU usage% on average stays much higher than it does under Dx11 and is main reason why I don't see screen pauses under Dx9 vs Dx11..................
:salute
-
I found this on reddit:
https://www.reddit.com/r/Windows10/comments/3oatuw/those_of_you_gaming_on_windows_10_heres_how_i/
It DOES NOT help me, but I thought I wouls ask Skuzzy what he thought of the reasoning behind it. It doesn't make sense to me that Microsoft would attempt to control the refresh rate of monitors from within Windows, but they being the same people that made Vista, and now Windows 10 . . .
-
I was free of this for a short time but it's back. I suspect this has already been stated but in case it hasn't, this problem is not limited to Windows 10. I am using W7 Ultimate and have the same problem. Perhaps the causes are different but the symptoms on the same. I see it on every map, at all locations, and in all GVs and planes. I see no correlation with location, sounds, action, or vehicle/plane.
-
Gonna go into MSI AB and check the box to disable ULPS in AMD driver and see if this stops then (Fiji GPU's support ULPS).....................
Update:
Set this up and tested in game.......didn't stop the screen pauses so it's not related to any AMD driver\GPU hardware level power control going awry.
At this time I am satisfied w\ all this as now I know that this isn't tied to AHIII client at all............
This is an issue between the OS and AMD driver stack when AHIII client is started using Dx11 API.
If anything this is demonstrating just how good AHIII is making use of my FuryX graphics card's post processing shader capabilities thru Dx11 vs Dx9 to perform all the graphics rendering\AA work which is offloading my graphics card's GPU to the point that the GPU is running out of work and isn't needed so it drops down to 0% activity until it receives draw calls from the game thru the OS to start back up doing work....sometimes this isn't happening fast enough to keep the graphics frame buffer filled w\ finished frames to display so the screen will momentarily pause when the buffer is emptied until the GPU can catch back up since most of the graphics work that the CPU did in times past has been offloaded to the GPU w\ AHIII so this is appearing to be a communication\timing issue that is between the OS's Dx11 API and AMD's drivers (path thru which the game instructions are communicated to the graphics card's GPU) so this would have to be rectified by AMD thru driver stack tuning for the AHIII client thru Dx11.........uh huh...........
As far as the rest goes this is in the bag now so until something else changes (maybe Vulkan...? :D) I'll just have to go w\ AHIII under Dx9.
Sorry Skuzzy but just liken me to being the 1 kid who keeps asking "why"............................
:D
:salute
-
so this is appearing to be a communication\timing issue that is between the OS's Dx11 API and AMD's drivers (path thru which the game instructions are communicated to the graphics card's GPU) so this would have to be rectified by AMD thru driver stack tuning for the AHIII client thru Dx11
Not claiming to understand this completely, but the same problem exists with Nvidia hardware and drivers.
Also, if it is not related to the AH3 client, wouldn't it be a common problem with other games and DX11? Is it?
-
Did some offline testing today and found that turning off shadows eliminated my stutters.
For some reason the shadows appear to be more taxing on my system, than turning environment map to all.
I was on the deck while doing my tests.
Shadows on: 40fps and game stuttered badly.
Shadows off: 60fps and game was smooth as silk.
Coogan
-
If your frame rate is less than the vertical refresh rate of your monitor, it is not uncommon to get stutters as the game surges and slows with the frame rate changes.
If your frame rate never drops below the vertical refresh rate, and you are getting stutters, it is, usually a different reason.
-
Skuzzy, are we any closer to finding the stutter source? :headscratch:
-
I do not know. We have some thoughts. They are all guesses though. Without being able to reproduce the problem it makes it damn difficult to figure what is causing it.
-
I do not know. We have some thoughts. They are all guesses though. Without being able to reproduce the problem it makes it damn difficult to figure what is causing it.
Did the stutters I experience show up in the .ahf films or only the YouTube videos I posted?
-
HiTech has those Ack-Ack. I know most of the films he has looked at has not shown anything one thing to be the issue. It is very random.
-
Not sure if its related, but I see odd distortions underneath the radio chat bar (especially if terrain is behind it) and through the prop. It appears to be map related, some have it some don't. Its like horizontal wash distortion.
I also had odd stutters on a couple of FSO maps (the North Africa/Italy one), where if I were in certain locations I would experience them.
-
Is it possible to issue a debug addon for the client to log parts of the session Hitech thinks causes this? I still get them from time to time in DX11 sessions, DX9 is steady.
-
Well, this is very disappointing. I had these stutters when AH3 first was released, but switching back to the DX9 version seemed to fix the issue.
No longer. My machine has not been deliberately altered (see PC specs link in signature), but this past week or so, my FPS number drops from 59-60 down into the low single digits about two or three times every minute. The screen pretty much freezes into immobility. I've tried all the suggested fixes listed here in the forums that I can find, but no joy. The game is simply not playable for me now.
-
I think that I may have found how to avoid stutters: turn AH filming off, turn skin downloads off, turn other plane's skins off. All three together seems to work, but the biggest gain appears to have been from turning off filming.
<crosses fingers>
-
I think that I may have found how to avoid stutters: turn AH filming off, turn skin downloads off, turn other plane's skins off. All three together seems to work, but the biggest gain appears to have been from turning off filming.
<crosses fingers>
I was having a lot of stutters and micro freezes last night. Logged out checked the task manager and found a windows component pulling up to 20% of my cpu. closed it down and went back in game and it was smooth as silk. Stupid windows :furious
-
I was having a lot of stutters and micro freezes last night. Logged out checked the task manager and found a windows component pulling up to 20% of my cpu. closed it down and went back in game and it was smooth as silk. Stupid windows :furious
What componet was ? :headscratch:
-
What componet was ? :headscratch:
mine was an "svhost". I had recently downloaded windows movie maker, and one of the things it wanted to do was to update a few codexs for the viewer. I guess it got hung on one of them and it was continually trying to look for/download some files.
-
If "svchost" is pulling a significant amount of cpu, right click and choose Go to Service(s) (in Win7) or expand it and see which service it refers to. If it's "wuauserv" it's the infamous Windows Update trying to find updates.
-
Not claiming to understand this completely, but the same problem exists with Nvidia hardware and drivers.
Also, if it is not related to the AH3 client, wouldn't it be a common problem with other games and DX11? Is it?
Here is a snippet of my Fury X's vitals in which I captured a screen freeze occurance after I had reset MSI AB to record GPU usage% in real form instead of in unified form (simply put unified time is an avg of the GPU usage% real time graphing) so you can clearly see the GPU usage% going to as low as 0% quite frequently (very, very little to no GPU activity) while under an actual AHIII Dx11 gaming use. The screen pause is due to the AMD driver somehow attempting to put the GPU to sleep due to a lack of work for the GPU to do (why the GPU clock speed drop along w\ the GPU FPS drop along w\ the GPU frametiming spike) after a certain amount of time in milliseconds in which the GPU usage% stays at 0. Once the GPU receives some work the driver then wakes the GPU back up then the screen resumes again. Since the rest of the system is still functioning normally (the vid card and driver are as well) you do not get a .dmp file as the OS\AHIII hasn't detected a hard fault occurance. I believe this is also happening w\ Nvidia hardware as well as both use a GPU power\clock speed control scheme (AMD PowerTune\Nvidia GPU Boost) that calculates using driver fed info as to the graphics draw\rendering\AA levels being used and neither does a good job at GPU control when the graphics loads are light.............
Since resetting my MSI AB graphs to show GPU usage % in real time, EVERY screen freeze seen since then is ALWAYS initiated by the GPU usage dropping to 0% (you can see on the graph that the GPU is doing this a LOT). My vid card's Fiji GPU supports ULPS (ultra low power state) which will be invoked when the drivers detect very low GPU loads to save power. Most of the time this shows up when AMD cards are set up in Crossfire (puts the 2nd vid card to sleep) but this "could" have been in effect on my single vid card thus my test by shutting this down and then seeing that this didn't stop the freezes so this indicates to me that this issue is an issue w\ AMD's PowerTune GPU control (Nvidia has a similar GPU control scheme called GPU Boost) which is implemented at the hardware level of the GPU but is fed info thru the drivers so that it can perform it's calculations to "optimize" the GPU.
None of these GPU control schemes whether Nvidia or AMD were tuned to provide decent control when the GPU's are LIGHTLY loaded....only HEAVILY loaded. Since AHIII is using the latest graphics techniques (post processing that offloads the GPU of the heavy rendering\AA work is 1 of them) and is multithreaded to boot, especially when being ran thru Dx11 API, can take much better advantage of Dx11's multithreading capabilities thus can spread out this work much more effectively across multi-core CPU's and can take much better advantage of a GPU's ability to process graphics calls in parallel by breaking up game graphics draw\rendering\AA calls into many threads instead of staying single threaded, this can tend to reduce the necessary amount of CPU\GPU processing time needed to do the same amount of work being multithreaded using multi-cored hardware vs single threaded which cannot take advantage of multi-cored hardware. This is just 1 of the attributes that Dx11 API brings to the table over Dx9 API that can lend to what I'm seeing occur on my box. There are others as well.
It is this lower CPU\GPU loading while under an AHIII game load under Dx11 that is the source of all of this going on (I can say w\ a fairly high degree of accuracy that this is the issue on my box from all the testing that I have done and the evidence provided) and the severity of the issue will depend on the specific computer configuration that AHIII is being run on. This is MUCH more prevalent when the game is running under Dx11 vs Dx9. On my box when I run the very same AHIII game client software using the exact same game settings both in-game and driver level under Dx9 I see none of these issues happening at all.....which points even more specifically to the differences between how the 2 MS Dx API's are handling\processing the game threads (not the AHIII client software itself) that the vid card drivers are then interpreting to then instruct the GPU to process.....the GPU operating loads while running the same AHIII game client software are VERY different w\ Dx9 showing a much heavier CPU\GPU game load than when under Dx11. If the issue was the AHIII game client itself the same issues should show up regardless of which Dx API it ran under. This is not the case on my box.
This can only be really fixed thru the vid card drivers to better control the GPU when they are under light game loads. HTC "could" "fix" this themselves by coding the game to more heavily load the CPU\GPU but that is really counterproductive for a game developer to fix an issue that is really for the vid card driver engineers to address (this is what they, Nvidia & AMD, are actually doing for most of the Tier 1 game developers big game titles so that their games run smoothly on their hardware......but last I checked HTC isn't on either's preferred list to get driver stack development support to ensure that AHIII runs smoothly). So IOW's, not all is equal w\ other game coding and driver support under any Dx API, much less Dx11..........just as not all is equal w\ the computer platforms this game is being used on which can either expose or hide certain anomalies in all aspects of computing from the software developer thru to the user.
This is really a 2-way aspect to be taken into context............not just a 1-sided affair in reality. The result of all my testing has shown for me that this issue rests on the AMD driver engineers to solve for AHIII as it is currently being used w\ Dx11.......which may not happen. At least they can't say they weren't notified as I have sent in a bug notice to AMD concerning this game's issues running on their products\drivers and have gotten a return email that says that they have received it.................all I can do as a user at this point. I have effectively removed all other aspects on my end by either proving that a particular part isn't the cause OR have found other parts of my full system to be in need of either a readjust or a replacement (readjusted Windows Power Plan to eliminate the GPU stutters being caused by my CPU going into low clocks\power state due to low CPU game loads triggering the Intel CEIST to cut CPU clocks\power; replaced a faulty ADSL modem\router w\ a much better unit that now provides full Gigabit LAN speeds, retuned both computer's NIC's to take full advantage of this then rerouted a spare phone line to get our fax machine off the ADSL line so our ADSL line is now a fully dedicated line for all Internet access only.....includes AHIII).
The only item left to solve on my end now is this intermittent screen pausing concerning AHIII and the results of my testing has shown that this issue is not w\ HTC's AHIII client software per se.
All HTC has done is worked their AHIII game code to the point of maximum efficiency, especially under Dx11, that is now starting to show up these types of anomalies that IMHO are the result of lower than "normal" game CPU\GPU loading relative to the Dx API it is run under.
This graph I presented below is pretty telling from my POV....................
:salute
-
The NVidia control panel offers "Power management mode", which, as I understand it, avoids having the driver put the GPU to sleep when under-utilized...
(http://kenshelby.us/images/NVIDIA-control-panel-01.png)
-
Well, it doesn't throttle power at least.
-
Just did some more reading & found out that my AMD Fiji GPU also has AMD's ZeroCore tech installed at the hardware level along w\ ULPS (this is another AMD power saving scheme that is designed to shut down a GPU due to low\no GPU usage to conserve power....usually supposed to be activated only w\ Crossfire multi-GPU setups.......comes w\ all AMD GCN desktop GPU's..............).
This may be what is causing the GPU to shut down momentarily due to the GPU going essentially into an idle state from the low game GPU usage% when the GPU usage drops down to 0% and stays there long enough for ZeroCore to initiate the sleep state then wakes the GPU back up after the drivers call for the GPU to do some work.
Read here: http://www.amd.com/PublishingImages/graphics/tables/hi-res/amd-zero-core-power-savings-large.png
http://www.amd.com/en-us/innovations/software-technologies/gcn
The NVidia control panel offers "Power management mode", which, as I understand it, avoids having the driver put the GPU to sleep when under-utilized...
(http://kenshelby.us/images/NVIDIA-control-panel-01.png)
AMD Crimson drivers also have a setting that does the same thing.....called Power Efficiency. When enabled the GPU's power is controlled by PowerTune and will give\cut power and GPU clock speeds to the GPU as it's calc's dictate according to the GPU's temp according to the graphics setting levels being used. When disabled (as I use it) the GPU is given full power thus full clocks all the time once a D3D app is detected running unless the GPU's operating temps exceed the upper threshold as set in AMD's PowerTune at which point PowerTune will override and start cutting power\clocks to cool the GPU to keep it below the max TDP (I just found this threshold on my FuryX yesterday since I've finally upgraded MSI AB to vers 4.3.0 which will now work w\ AMD Polaris GPU's thus Radeon WattMan so now all my previous MSI AB controls are now active again....PowerTune starts stepping the GPU back once the GPU temps exceed 68*C w\ max TDP of 75*C...found this by being able to reduce the lower fan speed% now all the way down to 0% due to Radeon WattMan so I have mine set to 10% now which holds the GPU right at the 67*C-68*C temp line to maintain max power levels to the Fiji GPU w\o interference).
I'm getting these screen pauses even w\ the GPU running at full power\clocks so this isn't the culprit, but this ZeroCore just may be what is causing this to happen on my box due to the low GPU usage issue....and there isn't any way to adjust this or access this from Radeon Settings and to date I haven't found anyone who has figured out a way to mod the Crimson drivers and I have set all the Crimson driver settings that do work w\ the AHIII game client to as high of settings that they go to to try to increase the GPU game load but so far have not gotten the screen pauses to stop as I haven't gotten the GPU activity\usage dropoffs to stop dropping to 0%.
These pauses happen very random and fortunately for me very seldom, otherwise the game runs excellent on my box using Dx11. When I installed the new Crimson ReLive 16.12.1 drivers these screen pauses went away when using AHIII under Dx11 and all was good until I upgraded to Crimson ReLive 16.12.2 drivers to get the fixes for ReLive installed....then they came back.
This sealed the deal for me that this was an AMD driver issue, most likely has something to do w\ ZeroCore not working properly but this is seen as normal driver behavior so thus won't trigger a hard fault and a .dmp dump as long as this doesn't cause the game\OS to crash....which it shouldn't. As of right now this can only be fixed by AMD.......if this is the culprit at hand.
Until I can find a surefire way to disable this ZeroCore to then test this......................... ...........
:salute
-
"...all was good until I upgraded to Crimson ReLive 16.12.2 drivers..."
Can you revert to the earlier version?
-
"...all was good until I upgraded to Crimson ReLive 16.12.2 drivers..."
Can you revert to the earlier version?
Hi Bino,
Yes I could reinstall the 16.12.1 drivers but most likely I won't do so as the fixes to AMD's ReLive software is more important to me as of this time and it's too easy to just run AHIII under Dx9 to get away from the screen pause issue as I don't have\use a VR headset (the main reason to run AHIII Dx11 version). The ReLive fixes were the main motivation behind me upgrading to the current drivers as I'm gonna use this more in the future.
As far as running AHIII Dx11 goes, the current issue isn't a show stopper for me as it currently is as I've stated that these pauses occur very random and very seldom so I'm just biding my time.
HTC (or eventually AMD) will resolve this little issue 1 way or another.
:salute
-
my AMD Fiji GPU
Your GPU might be running on Island Time :devil
-
Diving on field ack.... freeze... auger. :bhead
Sure hope this is fixed soon.
DX9
-
Anyone having a problem uploading a zip file???
-
Hi Bino,
Yes I could reinstall the 16.12.1 drivers but most likely I won't do so as the fixes to AMD's ReLive software is more important to me as of this time and it's too easy to just run AHIII under Dx9 to get away from the screen pause issue as I don't have\use a VR headset (the main reason to run AHIII Dx11 version). The ReLive fixes were the main motivation behind me upgrading to the current drivers as I'm gonna use this more in the future.
As far as running AHIII Dx11 goes, the current issue isn't a show stopper for me as it currently is as I've stated that these pauses occur very random and very seldom so I'm just biding my time.
HTC (or eventually AMD) will resolve this little issue 1 way or another.
:salute
Update:
When I got on my box this evening and opened Radeon Settings I had a notification that there was a new driver update available. Checked and found that the new driver wasn't a new Crimson version (ie Crimson 16.12.3) but an updated version of the current Crimson 16.12.2 drivers........? 1st time I've seen this................
So to entertain myself I checked off for the AMD installer to update the driver.........installer started up and asked if I wanted it to do a clean install....which I said yes then it asked me if I wanted to do an express install or a custom install..........of course I clicked on custom install then picked the 3 parts I've always picked...drivers, Radeon Settings & Vulkan. Then the installer took off & performed a clean uninstall, reboot then clean installed my choices. After this was done then the installer asked if I wanted to install ReLive, which I clicked yes then it installed ReLive then once this was done it asked if I wanted to restart which I said yes then it rebooted my box and all came up clean showing Radeon Crimson 16.12.2 drivers. Opened Radeon Settings & checked all settings........installer saved all previous settings in Radeon Settings AND ReLive. All looking good so far..................
Went in game using Dx11 and have been flying around for the last 1hr..........so far all has been looking good and the main thing............haven't witnessed a screen pause yet.
Will keep playing\testing but so far all is looking good w\ no runs, drips or errors......................
Let's see if this stays this way..........................
Kinda makes me curious to know if AMD has responded to the feedback that I sent in...........also wondering if I wasn't the only 1........
So far, so good......................... .....
FYI...................
:salute
PS---Driver update was the Radeon Crimson 16.12.2 WHQL version.........Installer updated the Crimson 16.12.2 Hotfix version..................
FYI..........................
:salute
-
Update:
Witnessed my 1st screen pause just a few minutes ago since the driver upgrade yesterday playing AHIII using Dx11....................snipp et provided below.
This time the GPU usage was recorded at 100% when this occurred instead of the 0% for all screen pause events prior to this 1 so this is a new twist to the same scenario on my box. GPU usage pattern is still showing the GPU usage to drop off fairly frequent.....still dropping to 0% as well. I haven't gone into registry and disabled ULPS yet (which is supposed to also disable ZeroCore, but............) to see if this stops the issue w\ these drivers............
Will continue to test this further to see if current pattern of occurance holds up before making any changes.
:salute
-
Still getting stutters but not as badly. I discovered my system was constantly trying to download Windows updates and fixed that issue which may have helped. The stutters I am currently getting all occur when someone keys up and talks on vox. If nobody is talking on vox the game is smooooooth.
-
Update:
I went into the Windows registry yesterday when I got home after work (to relieve some stress and relax..... :D) and looked up all instances of ULPS in the AMD driver stack\Windows registry....there are 17 of these that I found as follows:
ControlSet1:
Class
(4D36E968)
0000--1
Video
(EDE98AF)
0000--2
0001--3
0002--4
0003--5
0004--6
0005--7
Services
amdkmdag--8
ControlSet2:
Class
(4D36E968)
0000--9
Services
amdkmdag--10
CurrentControlSet:
Class
(4D36E968)
0000--11
Video
(EDE98AF)
0000--12
0001--13
0002--14
0003--15
0004--16
0005--17
I then tested this using MSI AB to disable ULPS (which is supposed to disable ZeroCore as well) then checked the registry afterwards and found that the software doesn't disable all instances present....only the instances listed under the Video (EDE98AF) strings in ControlSet1, ControlSet2 & CurrentControlSet. Not the ones listed under the Class (4D36E968) strings OR more importantly, the ones listed under Services amdkmdag (AMD External Events Utility....the service that enables all AMD Radeon Settings functionality in the AMD driver stack) which is also under ControlSet1 and ControlSet2. So MSI Afterburner will not effectively shut down ALL instances of ULPS (or ZeroCore). Don't know about any other software but my hunch is that they won't either.
Reading up on all this afterwards I found that most tweakers recommended to modify all instances that start w\ 0000 to disable ULPS. This coincides w\ what I saw from using MSI AB but this doesn't do anything to disable ULPS\ZeroCore at the Services level or Class level.
So I went into the registry to test this and disabled ULPS (hopefully ZeroCore as well) at ALL levels modifying the D-WORD string "EnableUlps" by changing the value from 1 to 0, but NOT the D-WORD string "EnableUlps_NA"....left this 1 alone and have been running tests since. The Crimson drivers are working just fine and so far.........knock on wood.........I haven't witnessed a screen pause yet. So here's hoping.........again.
Here's a snippet of my box running AHIII Patch 15 Dx11 this morning provided below.
Note how clean the GPU frametime graph line is now even though the GPU usage % is still swinging as before and still dropping down to 0% fairly frequently.
Continuing w\ testing...................... ...
:salute
PS---Here is a snippet of the graphs that I took after the initial changes were made yesterday evening for comparison.
-
Update:
After this evening I may have solved the screen pauses on my end.
I went back into the registry and rechecked for any traces of ULPS again and found a 3rd amdkmdag (under CurrentControlSet) instance that I had missed prior so there was 18 instances in all. Had ran a search on "amdkmdag" and found that this is the AMD driver kernel....the other instances (all others that were listed as 0000, 0001, etc) were associated w\ AMD's Crossfire so disabling these did my Fury X no good as it isn't in a Crossfire configuration but the 3 instances at the driver kernel "amdkmdag" should as this is at the heart of the driver so I reset all the others back to default (enabled) then disabled ULPS at all 3 instances of amdkmdag.
Then went into Radeon Settings and disabled AMD FRTC (so only FreeSynch enabled) then went into MSI AB and disabled custom fan speed adjust (to allow Radeon WattMan full control of my Fury X....read up that the WattMan control issues are w\ the AMD R9 2xx\3xx cards, not w\ the R9 Fury series) so MSI AB will monitor GPU only. Then went up after upgrading to AHIII Patch 16 Dx11...........
I immediately noted a difference in how the Fury X was running after all this was done....for the better. Appears that the frequent GPU cycling was due to AMD's FRTC interfering w\ the v-synch controls. GPU still cycles but not near as severe as before and in much better symmetry. Game ran fantastic w\ clean GPU frametime graph line to go w\ clean GPU FPS graph line........snippet provided below.
Note the GPU usage pattern change..............
So far I haven't witnessed a screen pause running AHIII Dx11 to date.
Will continue testing this......................
:salute
-
Glad it works for you. For most of us messing with the registry would be a disaster.
-
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 have found that driver 375.70 is the most stable and causes me zero stutters in AH3. It's from late October, 2016 and I reverted back to it after the update. I haven't updated since and have the best and most fluid game play. 8xAA, 16xAF, all sliders jacked up in AH3. Try it out.
-
Here is a technical understanding provided by Microsoft as to the cause of a typical graphical screen freeze\pause\flicker that we're seeing:
https://msdn.microsoft.com/en-us/windows/ff570087(v=vs.80).aspx
This applies to all Windows OS's from MS Vista to the present Win 10................
FYI....................
:salute
-
Nice explanation. It would be nice if they provided a fix.
-
https://msdn.microsoft.com/en-us/windows/hardware/ff557263(v=vs.85).aspx
In this link Microsoft gives some information on the potential causes that set off GPU TDR events..............
Essentially what MS is stating is that the GPU is taking too long to execute a task (DirectX GPU scheduler is giving a GPU a max of 2 secs to complete a graphics thread task from initiation at the CPU to execution at the GPU (across the DMA buffer path from CPU L3 cache to system mem cache then from system mem cache across the PCI-E bus to GPU, all handled by the DMA controller\mem controller)....if this doesn't happen within this allotted time the GPU scheduler will preempt (isolate) the task and start the TDR timer to wait for this task to complete....usually for the same 2 secs. If it does then the GPU scheduler will release the GPU back to the driver to resume normal graphics operation after the buffer is flushed (the screen freeze\pause\flicker), if it doesn't then the OS will initiate a bug check, force the driver\GPU to reset and restart (the warning that you usually should see "Display Driver "amdkmdag (or the Nvidia equivalent)" stopped responding and has successfully recovered") which sometimes will crash the app\game as well.
The potential causes given leaves no one item\cause out of the equasion or points to any 1 single item as the primary cause so be aware......
:salute
-
Here is video of my in game pauses
-
Here is the video mpg file
-
We are all not in IT or have time to fix something the game maker should be working on.
I have been a loyal Aces high subscriber since beta of the original version back in 1999. In my opinion AH3 is still in beta and they should be discounting subscribers until it works consistently.
I started to think it was my pc until I started reading this long thread full replies and requests for every tweak and twerk and dx this and dx that or whatever. I just upgraded my graphics card to gtx1060 to see all the nice eye candy.
It looks great it really does just fix the friggin freezing stutters already!
-
We are all not in IT or have time to fix something the game maker should be working on.
I have been a loyal Aces high subscriber since beta of the original version back in 1999. In my opinion AH3 is still in beta and they should be discounting subscribers until it works consistently.
I started to think it was my pc until I started reading this long thread full replies and requests for every tweak and twerk and dx this and dx that or whatever. I just upgraded my graphics card to gtx1060 to see all the nice eye candy.
It looks great it really does just fix the friggin freezing stutters already!
I think the purpose of this thread is to isolate and fix the problem.
Coogan ;)
-
I think the purpose of this thread is to isolate and fix the problem.
Coogan ;)
This :aok
Personally am happy to help in any way I can if it helps develop this unique game.
-DaddyAce
-
This :aok
Personally am happy to help in any way I can if it helps develop this unique game.
-DaddyAce
You can't fix what you can't find! Hitech and crew have been very up front on this issue, that have not been able to isolate it down to any specific issue. :rock
-
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.
-
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.
-
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.
-
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.
-
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?
:headscratch:
Will continue testing...................... .......
:salute
-
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?
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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....
-
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.
-
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......................... .
:salute
-
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
-
Definitely..get a local in for free sub..probe them while playing..they will probably like it too
-
Update:
Concerning the D3DCompiler_47.dll I did a little studying last night & I know now what this file is for so I'll remove this from the context.........for now (necessary for the game client's Dx9.x graphics coding to function correctly within Dx11 API.....).
So, unless the issue is found, the last resort will be for the game client to be totally rewritten for full native Dx11 functionality..........which would actually be IMHO the next logical step to take from my perspective and retire the Dx9.x code entirely..........but Hitech may see it differently.
Would be a LOT easier to do if the current version w\ the HLSL shader compiler was functioning clean.
Continuing w\ testing.................err, playing............
:salute
-
Update:
Since Patch 23 to current Patch 24 I haven't witnessed a single screen pause occur on my box while running under Dx11.
I read in the Patch 23 Release Notes #3 "there should be a frame rate increase near large fields and carriers" which indicates that y'all have changed something within the game client code that would have the potential to free up some CPU\GPU cycles and so this seems to have seemingly resolved the infrequent screen pausing\freezing on my box since.
Will continue to monitor this on my end but since Patch 23 it appears that all is working fine so far..................
FYI.......................... .
:salute
-
Update:
Since Patch 23 to current Patch 24 I haven't witnessed a single screen pause occur on my box while running under Dx11.
:salute
Same here. HTC :salute
-
So, unless the issue is found, the last resort will be for the game client to be totally rewritten for full native Dx11 functionality..........which would actually be IMHO the next logical step to take from my perspective and retire the Dx9.x code entirely..........but Hitech may see it differently.
When running the dx11 version of AH it is only dx11, and already is 100% native dx11.
HiTech
-
When running the dx11 version of AH it is only dx11, and already is 100% native dx11.
HiTech
Ah, Ok. Gotcha!
:salute
-
HTC in layman's term how did you fix the stutter and freeze problem?
Have not had a problem in sometime now.
-
I am seeing some stutters still, when I first log on. They seem to go away after 5 or 10 minutes.
-
I am not getting the stutters now, DX9 or DX11.
I am getting frame rate drops at certain fields in DX11, not tested DX9. Overall, it is getting there :)
-
Here is a snippet of the MSI AB graphs of my box running AHIII Patch26 Dx11 on my box along w\ snippets of the Crimson driver as well as the AHIII settings...............
Note the GPU frametime graph line..................
This is about as good as it's gonna get for smoothness for me........w\ no screen pauses\freezes detected to date since the advent of Patch 23.
Loving every minute of it!
:salute
-
Pudgie have you been keeping up with windows updates?
Me wonders if ms has helped with improved perf????????
-
Pudgie have you been keeping up with windows updates?
Me wonders if ms has helped with improved perf????????
Hi MADe,
I've been updating my OS manually for some time (I using Win 7 HP SP1) and the updates that I've seen have been the usual stuff.
Win 10 may be a different story altogether...............but I can't say as I'm not using it at this time.
I know they were talking up Game Mode awhile back.................
I've upgraded my vid card drivers yesterday to Crimson 17.2.1's since AMD has made these WHQL................saw no improvement over 16.12.2's but also saw no drop in performance either.
All else is the same...........
:salute
-
Stutters back....no change to anything, just logged on one night and voila', right when I was rolling in...<PAUSE>......gack :(
-
Had no stutters for a while, seems to do it every 5 minutes or so now.
-
Yep ..back :furious
-
Back to normal AH3. It was good while it lasted.
-
Turning off the "crystal voice" setting in my sound blaster settings stopped the stutter when I keyed up the mic.
-
Had no stutters for a while, seems to do it every 5 minutes or so now.
Possible something that "builds up" in the server? Since it appears it went away for all for a brief period after update and then "reappeared again' after xx amount of time....
Just guessing...but seems with the variance in systems that its hard to say its us.
Dobs
-
Possible something that "builds up" in the server? Since it appears it went away for all for a brief period after update and then "reappeared again' after xx amount of time....
Just guessing...but seems with the variance in systems that its hard to say its us.
Dobs
Seems like it all started back again with the Crater map. The Crater map is one of the most graphically pleasing maps in the game.
-
I'm still getting micro pauses whenevery I use range or channel VOX, and especically if I look around does the sound start with micro-stutters...mostly engine and VOX. Especially if I look up - sputtering.
DX11. Win10 patched to the wazoo. Nvidia 970GTX latest drivers. Sound Blaster Z.
-
Confirmed that the stutters seemed to have gone away for a bit but they're back.
-
I have noticed using the task manager that the moment the game stutters, the cpu usage drops (around 5-20%) then rises up again.
-
Im not sure if it is in my head, but they seem worse now. Or maybe I just got used to playing without the stutters
-
I have noticed using the task manager that the moment the game stutters, the cpu usage drops (around 5-20%) then rises up again.
Interesting.................. ....
:salute
-
The stutter effects physical CPU1 and CPU2 at the same time as well.
-
What's this dx9 and Dx11 versions? Do I need to download one or the other?
-
Just separate exe files within the game folder. Look for them there. One is for the DirectX11 version, the other for DirectX9.
Sent from my XT1585 using Tapatalk
-
Still get micro-freezes lasting a second on the Dx11 version. Frame rates still go into the crapper when near a port or CV while the game shows a rock solid 59fps.
-
DX9 - All good, no micro stutters that I notice.
DX11 without VR - micro pauses frequently, usually last a second or so
DX11 with VR - Cannot say I notice any micro pausing.
-
I've read all the posts and so far the definition of stutter/micro/hard etc freeze seems as nebulous as the source of the problem. :rolleyes:
Something I haven't seen mention is the hard video freezes like I get. The VR view reverts to a 2d box, the throttle goes to zero (and maybe some other controls, or trim), and sometimes if I had been using a hat view at the time the view will be stuck until that hat position is pushed and released again. A control has to be moved to reactivate them. It may occur at any time, but most frequently while approaching the larger bases.
So I take it to be helpful I need to get the DX file, record film and also NVIDIA Shadowplay at same time.
Does the AH film record the USB controller(ssssss...) data also? Seems to be a correlation there.
-
What you are describing sounds like a USB power brownout, where the voltage/current level drops below what the headset needs to run. Certainly can happen if you are not careful with how you distribute power loads across the USB hubs of the computer.
-
DX11 freezes getting worse...longer in duration. :furious
Can't believe the majority of the population see's this, and it can't be duplicated by the developers.
-
I switched back to DX11 with the new computer and they are still there and noticeable.
It's odd because a few patches ago I swear I can remember them being cured in DX11 for a patch or two.
Also what AKAK said about the CV things get choppy in and around the boat with the graphics up. It is only the boat everywhere else is fine.
-
Here's a funny bit, in my Oculus, I get ZERO freezes. Smooth as a baby's bottom. Switch back to normal mode, and it sometimes feels like I'm in the matrix. In-game pauses, sound stutters.
What's frustrating (being a former programmer) is that chances are it's something very very simple causing it. But with hundreds of thousands lines of code, you'd almost need something as powerful as Watson Analytics to look at it...and it ain't cheap.
Probably a semi-colon or a bracket out of place somewhere :rolleyes:
That said, the game isn't unplayable at all. Just a small nuisance. :salute
-
Really need to pay attention to the terrain and where on the terrain you are when it happens. It is one of the many variables we need to try and reproduce it.
-
Really need to pay attention to the terrain and where on the terrain you are when it happens. It is one of the many variables we need to try and reproduce it.
No problem. Will the psave command capture that info for you?
And is there anything else that we can do on our end that'll help you track it down? The game doesn't crash so there's no report there to send you. It's so unpredictable. Like catching a friggin quark! You know they're there but when and where they're gonna hit is total randomness.
Sent from my XT1585 using Tapatalk
-
psave only captures the position on the terrain. It does not capture the terrain name.
It is really looking like it is a series of events which leads to the manifestation of it and if you do not get the exact series right you cannot duplicate it. Even the timing of the events is crucial. Crazy making.
-
Using DX11.
WTF???? Really...this is bad... I'm getting 1 - 3 second freezes at least twice every 10 minutes. You gotta be kidding me this is really really bad. Can we get some idea from HiTech that they are even working on this?
I mean, I suck as a player. But flying for 5-10 minutes to get to a field and engage. Then do auger in because the game freezes on a straffing pass. Not fun anymore.
-
psave only captures the position on the terrain. It does not capture the terrain name.
It is really looking like it is a series of events which leads to the manifestation of it and if you do not get the exact series right you cannot duplicate it. Even the timing of the events is crucial. Crazy making.
Hmmmmm, still captures the terrain name on my PC unless I get a special download.
-1388,2026,-8102,0.0,0.0,94.2
gunnery
FOV = 58.7
-
Using DX11.
WTF???? Really...this is bad... I'm getting 1 - 3 second freezes at least twice every 10 minutes. You gotta be kidding me this is really really bad. Can we get some idea from HiTech that they are even working on this?
I mean, I suck as a player. But flying for 5-10 minutes to get to a field and engage. Then do auger in because the game freezes on a straffing pass. Not fun anymore.
Did you even READ the post just before yours, never mind the whole thread. Skuzzy said they are working on it and it is very hard to duplicate. Or did you post just to complain?
-
Hmmmmm, still captures the terrain name on my PC unless I get a special download.
-1388,2026,-8102,0.0,0.0,94.2
gunnery
FOV = 58.7
I stand corrected then. Must have been added during the Beta.
And it is not just a location issue. It seems to be related to several events conspiring to create the problem. If you are having a chronic problem with this (i.e. it happens every minute or two), it could be something else. A DXDIAG output might be revealing in that case.
-
Did you even READ the post just before yours, never mind the whole thread. Skuzzy said they are working on it and it is very hard to duplicate. Or did you post just to complain?
Guilty as charged ($15/month) Sorry, just very frustrating. Glad to hear they're looking at it. Maybe a notice in game might help instead of in the forums. I don't know who Skuzzy is (what's Skuzzy's role...moderator or developer?) and there is not a sticky on this issue...is there? And from the guys I've mentioned it to in game it's pretty pervasive.
If they're trying to catch it...that's gonna be a long wait. I suspect they need to instrument the code and start pulling data from users.
Good luck. Will be looking out for a notice in the upgrade notes.
-
Zampheer.. just use DX9 to launch game
thats what we all are doing
its in your aces high folder aceshigh9.exe
-
FWIW, yesternight I noticed that at a distance the port showed as a rectangle of sea with a bonfire in the middle of it. When I got closer, there was a .5 second freeze, after which the port looked normal. However, although I could duplicate the rectangularity, the freeze didn't reappear.
231825,15820,-293386,-41.7,-21.3,76.8
buzzsaw
FOV = 58.7
I also had a similar freeze before that occurring when someone spoke on range. Again, that was a one time event and may have been purely coincidental.
I tend to get the freezes at some 15 minutes intervals, one at a time.
DX11.
-
See Rule #4
-
You have a couple of different things going on there Bizman. I'd like to see a DXDIAG output of your computer.
Have any of you Windows 10 users gotten the Creators Update yet? I have one report that it cured the DX11 pauses, but that is very early and only one report. It may only mean the specific problem one user was having may have been corrected, but it still may not be related to the problem we are trying to nail down.
-
My system was updated last week. I still get micro pauses. DX diag attached.
-
Here you go, Skuzzy.
You may find out that my Nvidia drivers are not the latest ones. These seem to work, the ones from the last half a year or so give me the "stopped responding" message.
-
Bizman, your page file usage is larger than I would like to see. I also noted you have overclocked the CPU. Now, on that series you had to increase the FSB bus speed to overclock. If the FSB is not an even divisor of the RAM speed, then you are running out of sync, which may cause some odd things to happen.
If you run CPUID (www.cpuid.com) and select the "Memory" tab, it will tell you what the FSB to DRAM ratio is. For that CPU, 1:1 is best, but 1:2 is okay as well. You want to avoid odd numbers, like 1:3, or 1:5. I am not crazy about 1:4 either.
For that CPU, I have been setting the FSB to 400, and then adjusting the CPU multiplier down to 8, although you can try 9. It is very stable and quick.
My system was updated last week. I still get micro pauses. DX diag attached.
Micro stutters are a different problem than the one we are trying to nail down. Does it do it in the DX9 version?
You might want to disable that AMD HDMI audio pass through driver. Right now, you have three devices fighting for the audio path.
I am not saying any of the above will correct anything, but it will allow for less resource fighting.
Thank you both, for the information
-
Thanks, Skuzzy. Now I know better what to look at. My FSB to DRAM ratio is 1:1 so that should be no issue. I don't fancy odd numbers, either. 400 x 9.5 here, no issues that I can see. Then again, I may not necessarily know what to look at, only the obvious like blue screens.
As for the page file, how low should it be? It was double the amount before I rebooted.
-
Disregard that comment about the page file Bizman. I misread the numbers.
Do your pauses/stutters happen in DX9?
-
Disregard that comment about the page file Bizman. I misread the numbers.
Do your pauses/stutters happen in DX9?
Heh, you already got me worried a little bit, thinking I had missed something elementary...
Guess I should give Dx9 a try, never done that.
-
I don't use DX9. When I do, I go from over 100 FPS to well under 60.
Will see about elimination the competition with sound. Thanks :)
-
I don't use DX9. When I do, I go from over 100 FPS to well under 60.
Will see about elimination the competition with sound. Thanks :)
I have a theory about that. The lower frame rate may be due to DX9 doing something DX11 is not doing in order to prevent resource starvation on the video card and that is why we do not see that long pause in DX9.
Just a theory, at the moment.
You should be running with vertical sync enabled, or is your monitor refresh rate over 60?
-
Monitor refresh rate stated is 144 in documentation. Video Card Settings shows it at 143.85.
The Aces High Video Settings for V sync is not checked. Should this be checked or not checked?
-
Disable vsync should not be checked in the games "Video Settings".
Would you mind trying DX9 for a bit, just to see if the pause disappears?
-
Will do.
Still had stutter a few moments ago with sound device disabled. Had not checked the vsysnc square :)
-
Did a short 15 minute flight or so in a heavy P38L. Dropped Bombs on DAR and used rockets on ground guns. I then went to another field with a good bar dar both green and red. Numbers went from a low of 71 to a high of 143, changing almost constantly. I did not note a stutter or freeze. I shall continue with DX 9 and will let you know if I see any stutters or pauses. Thanks for the information. :aok
-
Thanks for the testing.
I did not expect the errant sound device to be the cause. Was just noting it was taking away resources.
-
Flew about two hours 5/16/17 using DX9 I melee. Many times with very, very large DAR Bars. No instance of stutter or Freeze on my system. So, I guess if I do not require DX11 for play, then I shall stick with DX9. Thanks for assistance :aok
-
Thank you. Good information.
-
Since I upgraded to this AMD Ryzen 7 1800X\Gigabyte AX370 Gaming K5 mobo using Win 10 Home I still get the screen pauses, but they are even more remote and infrequent than they were occuring on my Intel I7 5820K\Gigabyte X99M Gaming 5 mobo using Win 7 HP SP1 but I was thinking that this was mostly due to the Dx11 graphics adjustment y'all made to the AHIII client.
It's down to the point that now I may see 1 instance occur every 2 or 3 days of game play instead of 1-2 instances every gaming session.
FYI.
:salute
-
If anyone runs into other things which seems to have cured the stutters, please post them in this thread, and I will incorporate them into this post. Be sure to state the game version you are running (DX9, DX11 and version/patch level).
I've had had short freezes on releasing the radio transmit button. Cheap USB device, QX1002USB. Ever since, I've simply been running the windows7 audio recorder (SoundRecorder.exe) in the background, and the freezes are gone. Just made it a habbit of launching it together with stick mapping tool before running AH.
Since it's been a while now, just retried without running it, and stutters can still be reproduced like on day 1.
-
I've had had short freezes on releasing the radio transmit button. Cheap USB device, QX1002USB. Ever since, I've simply been running the windows7 audio recorder (SoundRecorder.exe) in the background, and the freezes are gone. Just made it a habbit of launching it together with stick mapping tool before running AH.
Since it's been a while now, just retried without running it, and stutters can still be reproduced like on day 1.
There is not anything we can about that. Have you made sure the USB port is powered all the time in Windows power management?
-
There is not anything we can about that. Have you made sure the USB port is powered all the time in Windows power management?
At least disallowed disabling to save power, and disabled selective power management.
I'm not expecting a solution (can never lose hope though), but just posted what has worked for me to solve the freezes I was seeing, because you were asking for anything that has helped. Running the recorder (recording not necessary) has worked perfectly reliably for me. Having the "recording" tab of the "sound" devices list open works, too. Just thought you might want to include it in your summarized list.
-
Dx11 still getting off stutter
-
Ran updater & updated to AHIII 3.01 Patch 3 then ran the game..............
Screen pauses are still showing up on my box.
Using the Dx11 version.
FYI
:salute
-
Same here Pudgie, but the pauses are not as frequent.
-
Ran DX11 for a bit last night, I only ran into one pause. I saw no stutter but I happened not to spend much time near enemy bases.
Wiley.
-
Dx11 still getting off stutter
+1 when i read the notes I got a little excited that it may have been cured, worked ok for all of 5 minutes then a couple of pauses.
-
Dx9 I'm getting freezes with a recovery frame rate at 30+ quickly improving to 59.
I can not pin to anything but seems to be with graphics loading. I've got a slow gc so that could fit in the picture some how.
-
Dx9 I'm getting freezes with a recovery frame rate at 30+ quickly improving to 59.
I can not pin to anything but seems to be with graphics loading. I've got a slow gc so that could fit in the picture some how.
If it is in DX(, there is not much we can do about it as it usually means something is taking the CPU away from running the game. A DXDIAG output might show something.
-
I have been doing some flight testing using DX9 version and had a major (multi-second) pause flying offline in the training arena. The scenario was a spiral down from altitude and the pause occurred quite low the ground. I was recording at the time, so you can see the pause in the instrument freeze.
-
Update:
Messing around this afternoon I got to thinking about this screen pausing\freezing issue some more then went back thru the saved MSI AB graphs that I had captured showing these screen freezes & I finally noticed that the CPU was also showing to slow down as well as the GPU when these would occur.
So I started AHIII Dx11 but instead of going online I went offline (to eliminate the Internet\Nighthawk\Intel LAN) and flew around for a while shooting at the drones trying to push my box as hard as I could then shut down & pulled up my MSI AB graphs of my box running and quickly noticed that the GPU frametime, FPS, CPU core usage graphs were showing the game to run extraordinarily smooth & very steady......when I compared these against the graphs that I snipped after online sessions this indicated to me that my CPU was getting hammered thru the connection which would be directly related to the setup of my Intel NIC so I went into the NIC settings & started making some setting changes then would go online, run the game from the same place on the map to try to maintain some semblance of consistency.
What I've found out is that I had made some setting changes that I thought were helping my connection get better but in the process actually had increased the amount of CPU utilization by a LOT & this excessively high CPU utilization just may have been the culprit that was causing the screen freezes. I'll continue to test after this but so far so good.
The LAN settings that I made corrections to are as follows:
Jumbo Packet Size---this setting will allow a packet to become larger than the std MTU packet size in order to reduce the amount of CPU utilization IF the routing equipment along the way supports this. I had set this to the max size of 9K thinking this would help since I have this Netgear Nighthawk AC1900 ADSL modem\router running 1Gb link speed....but found that this was actually hurting my connection by excessive packet fragmentation causing the CPU to waste cycles sorting all this out. I have now disabled this setting so that the packets will return back to the set MTU size of 1.5K or 1500. This made a BIG difference.
Packet Priority & VLAN--this setting enables priority sending & receiving of certain types of packets that are tagged for priority (QoS) or are tagged for use across a VLAN. I found this setting enabled to provide both priority & VLAN tagging.....so I disabled this as I don't operate a data center network that could use this & upon testing in-game noted my CPU utilization drop some more. Made more of a difference.
Transmit & Receive Buffers--these settings set the buffer size in system mem for the NIC to use when writing packet data that is to be transmitted out across the Internet (so the NIC can continue to process outgoing packet data w\o a buffer overrun) or storing data received from the Internet to allow the NIC to continue to receive incoming packet data while processing packet data that the CPU can then fetch the stored sequential packet data from this buffer w\o overrun. Typically I have set these to the largest buffer size allowed by the NIC driver...which was 2048 for both transmit & receive buffers but I reset these back to the default size of 256 for the receive buffer & 512 for the transmit buffer which seemed to help the CPU even more but it also showed to be a little too small as I started seeing warping show up on my end so I reset these buffers as follows: transmit buffer @ 1024 & receive buffer @ 512. After doing this my connection calmed down & all was smooth & steady w\ the running CPU thread usage hardly going over 55% & the GPU frametime graph line was showing the cleanest, smoothest graph line I have witnessed to date from my Team Red box & all was just beautiful..........so far I haven't witnessed a screen freeze\pause since doing all this.
Yep, we've been here before on other occasions so I will run this for some time to see if this was really the cause of this issue on my box. Can't explain why AHIII Dx9 client would run using my Intel LAN set up the way it was prior w\o screen pauses\freezes.........
If this does pan out to be true then I will be kicking myself for not checking this out earlier...................
FYI.......................... .
:salute
-
I have been doing some flight testing using DX9 version and had a major (multi-second) pause flying offline in the training arena. The scenario was a spiral down from altitude and the pause occurred quite low the ground. I was recording at the time, so you can see the pause in the instrument freeze.
DX9 does not have the long pause issue we have had reports of in DX11. If you are getting it in the DX9 version, then it is more than likely something else, which can be corrected.
Just need to start with a DXDIAG output and we can go from there.
-
dont know if its been mentioned in this thread but it appears all of my DX11 pauses are when the weather or lighting changes drastically.
-
Mine appear to be completely random. Stutter here. Stutter there. No stutter for a while, then a couple in 30 secs. Some nights hardly at all. A really odd problem so quite obvious why it's been so hard to pin down.
Sent from my XT1585 using Tapatalk
-
Here is an AHIII film of my box while flying.
You will note several instances of the film stuttering (even though I saw no such stuttering going on while flying) while I was flying.
The 1 instance that I would guide you to occurred at the 9:12 mark as that stutter is a screen pause\freeze that was captured in which you can clearly see the film skip ahead momentarily going out of synch then returning & I could clearly see the graphics motion stop completely for approx .5 secs then resume while I was flying.
Sending this to y'all for diagnosis to see if you can find anything from it.
:salute
PS--I have also provided a dxdiag of my box using the Crimson 17.8.1 drivers. You will find the AMD HDMI sound drivers are loaded along w\ the Creative SB X7 sound drivers...the AMD HDMI drivers are disabled in Win 10 so they aren't active. This is due to Win 10 continuing to reinstall the Windows version of these drivers on it's own after I delete them so I took a page out of Chalenge's book & disabled them instead to stop Windows from reinstalling them.
FYI........
:salute
-
Inside Steam does aces high default to dx11? Cause I get a huge pause every few mins. Rather annoying. If there's anythint I can do to help I will.
-
We had to default the Steam version to DX11. No choice there due to the VR support.
-
yep. First thing I noticed was it was DX11 and lag pauses galore.
-
so - did the latest version fixed the stutter for you? I had none at first but they eventually came, maybe not as pronounced.
-
The latest version of the game would not have fixed it. This has been the issue all along. The inconsistency of the problem.
-
I have read that the problem could be caused by GPU throttling. EVGA distributes a software that locks the gpu freq to the max, I'll try that out.
-
I have read that the problem could be caused by GPU throttling. EVGA distributes a software that locks the gpu freq to the max, I'll try that out.
I overclock mine with Afterburner. The clock freqs I select in a profile stay constant when gaming in 3d. I still get stutters. That was before and after upgrading from a R6950 2gb to a 1060 6gb. So even both genres of video card, AMD and Nvidia.
Sent from my XT1585 using Tapatalk
-
I do not think it is the video card throttling. It really wreaks of some type of resource issue outside of the game. The fact it does not happen reliably and the frequency is variable based on the hardware is just maddening.
-
I overclock mine with Afterburner. The clock freqs I select in a profile stay constant when gaming in 3d. I still get stutters. That was before and after upgrading from a R6950 2gb to a 1060 6gb. So even both genres of video card, AMD and Nvidia.
Sent from my XT1585 using Tapatalk
I have a 1060 6 gb what have you OC yours to?
-
I do not think it is the video card throttling. It really wreaks of some type of resource issue outside of the game. The fact it does not happen reliably and the frequency is variable based on the hardware is just maddening.
I focused on videocard because my freezes are often accompanied (?) with a partial texture reload, but likewise the sound completely frozen during it...IRQ issues? :D
I hear that you don't have any issues on your office's computers, is there anything special that you do when you deploy them?
I'll keep brainstorming...
-
I am a fanatic about running clean systems. We do not have much of anything installed which is not needed to do the job.
HiTech has an issue, once in a while, when Windows 10 decides to do an update. It wreaks havoc with his development system when it happens and usually costs us a good half day to fix.
-
I have a 1060 6 gb what have you OC yours to?
Mine is an MSI GamingX card with a really good cooler on it, which is why I bought it. I'm at 2100 core, 4374 Memory, 108 power limit. I never break 65c in the Unigine stress tests.
If you're not experienced in overclocking read up on it before you just plug settings into afterburner. Baby steps and a lot of patience are key. My card and my rig and my cooling are gonna be different from yours. Your overclockability will likely vary from mine. Don't fry your card! Just a brief PSA about overclocking. :D
That and let's not hijack this thread. :aok
-
Mine is an MSI GamingX card with a really good cooler on it, which is why I bought it. I'm at 2100 core, 4374 Memory, 108 power limit. I never break 65c in the Unigine stress tests.
If you're not experienced in overclocking read up on it before you just plug settings into afterburner. Baby steps and a lot of patience are key. My card and my rig and my cooling are gonna be different from yours. Your overclockability will likely vary from mine. Don't fry your card! Just a brief PSA about overclocking. :D
That and let's not hijack this thread. :aok
I got 2 fans on mine. Stock cooler I assume. I do wanna turn her up tho ;)
-
Update:
I have ran AHIII Dx11 a couple of times w\ LatencyMon 6.5 running in the background to check if I'm getting hit w\ a lot of DPC's off ISR's being generated by any running drivers on my Team Red box, hoping that a screen pause\freeze would occur while LatencyMon was running to see if it would pick this up & identify the culprit..........
As you would have it, my box has ran flawless while this app was running so I haven't got anything so far except LatencyMon showed that there were a lot of ISR's w\ subsequent DPC's generated by this MS Win 10 OS file: wdf01000.sys (MS Kernel Mode Driver Framework) but the execution times were very short & LatencyMon reported that Team Red was running fine w\ no dropouts......but that's a lot of CPU context switching going on that is somewhat driver related...........it doesn't appear to be sound driver related but could be graphics driver related as this MS Win 10 OS file: dxgkrnl.sys (MS Directx Graphics Kernel) wasn't showing any ISR counts but was showing a few DPC's though.
Gonna keep testing to see if I can capture something.................... .
Snippets of LatencyMon results provided below.
FYI.......................... .
:salute
-
Update:
I finally caught a screen pause\freeze while flying AHIII Dx11 vers w\ LatencyMon running in the background.
Snippets of the results provided below.
It appears to be driver-related w\ LatencyMon reporting a potential buffer underrun w\ a potential CPU power management warning due to CPU throttling (I have AMD's Cool & Quiet CPU power\temp control enabled in UEFI & am using the Windows Balanced Power Plan but Powercfg.exe has been modified so that when CPU core usage % exceeds 40%--which is all the time once AHIII is running in full screen--Cool & Quiet will give this 1800X full power to all 8 CPU's so the CPU is running @ 3.7Ghz on all 8 CPU cores consistently and won't back off until CPU core usage % recedes below 30%--which won't happen until AHIII has exited back to desktop) w\ a suggest to update BIOS to latest vers (which I already have done so).
The only driver showing to be getting ISR's & DPC's is the MS wdf01000.sys (MS Kernel Mode Driver Framework) and MS dxgkrnl.sys (MS Directx Graphics Kernel) not showing any ISR's but quite a few DPC's. None of the Creative SBX7 drivers show any ISR's or DPC's to suggest that there is an issue w\ them but I'll check them for the allocated buffer size. Do the graphics drivers have a buffer allocated to them & is this buffer a dynamic one or a fixed size buffer? I'm sure there is 1 but I've never seen evidence of it OR where it can be set. I'll assume that this buffer is located within the graphics card's onboard mem & is accessible thru the vBIOS controlled thru the graphics card driver.
Maybe on to something here.
Got some homework to do.........................
:salute
-
ever since VR my stutters have vanished
-
Yes, the VR headsets have never suffered the issue. That is what got us thinking about where the issue may be.
-
Update:
After doing some homework I think I may have at least come to some better understanding of what is occurring in the background.
From LatencyMon showing the 2 Windows 10 files wdf01000.sys (MS Kernel Mode Driver Framework) & dxgkrnl.sys (MS Directx Graphics Kernel) w\ wdf01000.sys getting a lot of ISR's (interrupt service routine) & DPC's (deferred procedure call) and dxgkrnl.sys getting no ISR's but several DPC's........
The wdf01000.sys is part of the Windows Driver Framework stack that the graphics card driver (AMD or Nvidia) is signalling Windows to signal the CPU to request data (interrupt) to be sent to the GPU (whether from the CPU's L3 cache or system mem cache) thus the ISR. The large amount of DPC's is due to something else blocking these requests from being executed in a timely manner at the CPU core level momentarily (higher rank thread priority due to thread scheduling by the Windows scheduler, 3rd party software execution, poorly written software...., damaged Windows files from bad\incomplete driver installations, thread held up waiting on another thread to finish to fetch the data from that thread to finish the other one, etc) which slows down the data transmit requests from the CPU to GPU. The dxgkrnl.sys is part of the Windows 10 Directx Graphics Kernel that processes the Directx 3D application of the graphics data requested earlier. The absence of ISR's is due to the kernel being embedded within the Driver Framework stack but needs CPU core processing time to do it's work & the number of DPC's indicate that there is something also blocking it from being executed in a timely manner at the CPU core level momentarily as well which also slows down the Directx application to the needed data which slows down this data getting to the GPU in a timely manner. This situation is referred to as "resource starvation". The amount of time duration for each individual DPC to complete is very small, but when you have a large amount of DPC's occurring the total duration time does add up to some significant slow downs of graphics data transmission when under a game load.
Now some of this does occur within the normal processes so the fact that there are DPC's at all isn't the issue per se....it's when there are an EXCESSIVE amount of these DPC's occurring within the graphics computation pipeline that can cause the graphics frame buffer to be underrun (frames are moved out of the buffer to be displayed faster than the finished frames are being moved in to be displayed) & when this reaches the 0 point the screen will stop momentarily as there are no finished graphics frames to be displayed to screen until there are enough finished frames refilled to the graphics frame buffer to continue displaying to the screen then the screen motion will restart.....as long as this happens within the 2 sec threshold then no TDR will occur (why we ain't getting .dmp files). This is why these events are so random as there is no way to reliably predict when the buffer underrun will actually occur & what exactly is causing it. The only thing I do know now is what part of the system is being affected. The number of causes are very large w\ most of these causes being created outside of the AHIII client's domain so Hitech & Co will be essentially limited in what they can do from their end. The fact that these screen freezes aren't occurring when the AHIII DX11 client software is running in offline mode is an indicator of the base level of AHIII DX11 client being intact & error free code-wise.
SO I've been out on the Internet looking for any & all info on using all the built-in Windows tools that can be accessed thru the CMD to start going thru the OS to see if I can find anything amiss on my end & if I find something I'll post.
At least now I have a little more to go on when I start looking........
FYI........................
Now it's time to get outside & pour some cement.................
:D
:salute
-
very nice thanks for the writeup, I will go to sleep less ignorant tonight :aok :salute
-
One other item I forgot to add.....................
When looking at LatencyMon results w\ the screen freeze\pause captured, the latency issue was occurring the vast majority of the time on CPU core 0 (or CPU core 1 if you prefer) w\ AHIII Dx11 version being run w\ CPU core priority\affinity applied which means that the game threads weren't being processed on CPU core 0 as I had instructed Windows to assign these threads to other CPU cores......which also moves the AHIII game client from being the cause in my mind........
CPU core 0 is handling the majority of it's processing time the OS 1st due to high priority being assigned to itself then any device drivers & related software, 3rd party software, etc.......everything except the AHIII game threads w\ CPU core 0 latency being 3 times worse than the rest of the CPU cores..........
Since Windows Scheduler schedules threads using a round robin method according to the binary CPU core numbering (which means that it will try to schedule as many threads, regardless of which process that generated them, as it can to CPU core 0 unless the CPU core is tied up) this can lead to CPU core contention on this core which can affect the Windows Driver Framework stack's operation & create these DPC's.
When you have a 8-core CPU available w\ Windows only trying to use less than 1\2 of them there is an issue that needs to be resolved there as well.
:salute
-
Ok, this is what I have went thru to date:
1. Ran the following thru the Windows CMD Editor to check Windows 10 image on my box:
sfc scannow----> Reported back clean w\ no errors found after scan was run
DISM.exe /Online /Cleanup-Image /ScanHealth----->Reported back image was repairable after scan was run (even though SFC reported all clean)
DISM.exe /Online /Cleanup-Image /RestoreHealth----->Ran it anyway......reported back all completed successfully so Windows 10 image checks out as clean.
Went in AHIII & flew around for awhile..........got a screen freeze\pause afterwards so not due to Windows 10 OS issues.
Ran LatencyMon.......still shows the 2 MS Windows files (wdf01000.sys\dxgkrnl.sys) getting hit w\ excessive ISR's\DPC's.
Bing'd these 2 files to see if any fixes\solutions available............
1. wdf01000.sys------->Got 1 suggestion to go into BCDedit /set IncreaseUserVA 3072 (this was setting to increase amount of addressable mem of 4Gb total system on x86 Windows OS to user mode from the std 2048 to the max of 3072--3Gb--to help alleviate mem resource starvation of the Windows Driver Framework Kernel....does me no good as I'm using Win 10 x64 OS which doesn't have this limitation), doesn't apply but I tried it anyway then retested...........and got a screen freeze\pause so validated this ain't it.
2. dxgkrnl.sys----------> Got 1 suggestion to go into BCDedit /set disabledynamictick yes (this setting would stop Windows from dynamically switching timers based on the application needs). Now since I have this AMD Ryzen 7 CPU that likes the HPET timer to be active & had already set this prior for Windows to use the HPET I set this to yes to keep all using the HPET just to see what would happen.........AHIII ran much snappier after this was done (LatencyMon did show that the ISR\DPC execution times did reduce across the board after making this setting change which verified the performance improvement) but I still got a screen freeze\pause to occur but only after a couple of hours of game play had elasped. Liked what I had but wasn't the culprit of causing the screen freeze\pause..........
So now this points to start shutting down stuff I have running in the background as follows:
1. Shut down HWINFO32------->Still got a screen pause\freeze to occur-----not the culprit (was glad to see this)
2. Shut down MSI AB\RTSS next----->Still got a screen pause\freeze to occur-----not the culprit (was glad to see this as well)
Note: These 2 programs make up the overlay that I'm currently using to do real time monitoring of my box while flying.
3. Shut down Gigabyte APP Center w\ all sub apps next-------->Still got a screen pause\freeze to occur------not the culprit
4. Shut down Logitech Keyboard & Mouse Control next------>Still got a screen freeze\pause to occur----------not the culprit
5. Shut down CorsairLink4 Monitoring\Control (H80i V2 AIO) next------->Still got a screen pause\freeze to occur------not the culprit
6. Shut down Samsung Magician SSD Monitoring\Maintenance Software next------->Still got a screen pause\freeze to occur-----not the culprit
7. Checked settings in Webroot SecureAnywhere AntiVirus for Gamers......found some settings that would allow AV to update itself automatically--turned this off, found AV set under Access Control to actively monitor HWINFO32 software & SB X7 DAC-AMP driver while they were running-?, set AV to allow both HWINFO32 & SB X7 DAC-AMP to run unhindered, found that AV System Optimizer has never ran due to not being enabled (this cleans up all the junk files left behind from system operations)...set this up to run upon system bootup as well as AV to scan all on system bootup & not on a schedule.
Am in the process of testing out all this at the time of typing this post.................
This is what I have covered on my box so far.
FYI..........................
:salute
-
Ok, this is what I have went thru to date:
1. Ran the following thru the Windows CMD Editor to check Windows 10 image on my box:
sfc scannow----> Reported back clean w\ no errors found after scan was run
DISM.exe /Online /Cleanup-Image /ScanHealth----->Reported back image was repairable after scan was run (even though SFC reported all clean)
DISM.exe /Online /Cleanup-Image /RestoreHealth----->Ran it anyway......reported back all completed successfully so Windows 10 image checks out as clean.
Went in AHIII & flew around for awhile..........got a screen freeze\pause afterwards so not due to Windows 10 OS issues.
Ran LatencyMon.......still shows the 2 MS Windows files (wdf01000.sys\dxgkrnl.sys) getting hit w\ excessive ISR's\DPC's.
Bing'd these 2 files to see if any fixes\solutions available............
1. wdf01000.sys------->Got 1 suggestion to go into BCDedit /set IncreaseUserVA 3072 (this was setting to increase amount of addressable mem of 4Gb total system on x86 Windows OS to user mode from the std 2048 to the max of 3072--3Gb--to help alleviate mem resource starvation of the Windows Driver Framework Kernel....does me no good as I'm using Win 10 x64 OS which doesn't have this limitation), doesn't apply but I tried it anyway then retested...........and got a screen freeze\pause so validated this ain't it.
2. dxgkrnl.sys----------> Got 1 suggestion to go into BCDedit /set disabledynamictick yes (this setting would stop Windows from dynamically switching timers based on the application needs). Now since I have this AMD Ryzen 7 CPU that likes the HPET timer to be active & had already set this prior for Windows to use the HPET I set this to yes to keep all using the HPET just to see what would happen.........AHIII ran much snappier after this was done (LatencyMon did show that the ISR\DPC execution times did reduce across the board after making this setting change which verified the performance improvement) but I still got a screen freeze\pause to occur but only after a couple of hours of game play had elasped. Liked what I had but wasn't the culprit of causing the screen freeze\pause..........
So now this points to start shutting down stuff I have running in the background as follows:
1. Shut down HWINFO32------->Still got a screen pause\freeze to occur-----not the culprit (was glad to see this)
2. Shut down MSI AB\RTSS next----->Still got a screen pause\freeze to occur-----not the culprit (was glad to see this as well)
Note: These 2 programs make up the overlay that I'm currently using to do real time monitoring of my box while flying.
3. Shut down Gigabyte APP Center w\ all sub apps next-------->Still got a screen pause\freeze to occur------not the culprit
4. Shut down Logitech Keyboard & Mouse Control next------>Still got a screen freeze\pause to occur----------not the culprit
5. Shut down CorsairLink4 Monitoring\Control (H80i V2 AIO) next------->Still got a screen pause\freeze to occur------not the culprit
6. Shut down Samsung Magician SSD Monitoring\Maintenance Software next------->Still got a screen pause\freeze to occur-----not the culprit
7. Checked settings in Webroot SecureAnywhere AntiVirus for Gamers......found some settings that would allow AV to update itself automatically--turned this off, found AV set under Access Control to actively monitor HWINFO32 software & SB X7 DAC-AMP driver while they were running-?, set AV to allow both HWINFO32 & SB X7 DAC-AMP to run unhindered, found that AV System Optimizer has never ran due to not being enabled (this cleans up all the junk files left behind from system operations)...set this up to run upon system bootup as well as AV to scan all on system bootup & not on a schedule.
Am in the process of testing out all this at the time of typing this post.................
This is what I have covered on my box so far.
FYI..........................
:salute
Update:
Have gone thru Webroot w\ a fine tooth comb working all settings that should have not allowed Webroot to interfere w\ the game but I still got a screen freeze\pause..............
8. Shut down Webroot SecureAnywhere Antivirus completely today next & ensured that it was completely shut down then ran AHIII Dx11 vers....still got a screen pause\freeze......AV is not the culprit (glad to see this). So I have restarted Webroot SecureAnywhere Antivirus software, reset all settings back to prior test setup but went ahead & set up AHIII in both Dx9 & Dx11 versions to be allowed to run unhindered (AV wasn't hindering the game anyway).
Put all my monitoring software back in pre-test setup as none of them were found to be the culprit.
So, after all this testing it appears that none of the software (OS, monitoring apps, AV, services, etc) that I have running on my box is responsible for these screen pauses\freezes occurring so unless I've missed something I'm gonna have to look into my hardware.....
9. SB X7 DAC-AMP------> Had this DAC's USB cable plugged into 1 of the onboard USB 3.0 rear ports that is designed w\ Gigabyte's USB DAC-UP2 power regulation control to provide clean power to assist external sound interfaces to operate smoothly. Had reset the line power calibration from normal to +.3v additional power then ran the game.........got screen pauses to occur at each power reg point.........not the culprit.
Installed a spare USB 2.0 rear adapter & plugged the X7 into this adapter to run the DAC off the internal USB 2.0 ports (this DAC was built to USB 2.0 specs--info on Creative's site of sound pops, static if DAC is plugged into USB 3.0 header....would get 1 or 2 pops every blue moon) then ran the game.....still got a screen pause\freeze.......not the culprit.
Reconnected the X7 DAC back to the USB 3.0 rear USB DAC-UP2 header.
10. Orico PUV3-7 USB-to-PCI-E add-in card-------->Have noted some spiking occurring w\ my CH USB HOTAS that I think is due to the VIA USB chipset that this add-in card uses. A quick in-game recalibration fixes it for a while but will start wandering & occasionally will spike my throttle w\ throttle handle pulled back (idle) so wondering if USB spiking is causing this..........
Since I got this Fractal Design Meshify C case the USB connectors from my HOTAS didn't want to fit thru the case expansion slots w\o some force applied to them (USB slots in this add-in card run perpendicular to the expansion slot) to plug into this card....this ain't good either so I have ordered a Sunix 4-port USB 3.0-to-PCI-E USB add-in card in that the USB connectors plug in parallel to the case expansion slots to eliminate the connector binding and this Sunix card uses a Renasaus USB chipset that from reading up these USB chipsets are reported to be good, clean, stable USB chipsets. I did have an issue getting the Orico PUV3-7's driver to install so was using a USB driver provided thru Win 10. Should have the Sunix USB add-in card by Wednesday.................we'll find out then. Was looking for a USB 2.0 version of this card but none to be found........at least on Newegg.
This is where I'm at to date........
:salute
-
Wow Pudgie, you've done a lot of digging to try and ferret this out man! :aok :salute
-
Update:
Worked w\ CPU as follows:
Enabled High Performance Power Plan so CPU will run at full clocks (even though AMD Cool & Quiet is still enabled in UEFI) then ran the game......played for approx 25 mins w\ steady CPu clocks @ 3.7 Ghz.........but got a screen freeze to still occur.
Got an idea............
Went & enabled the Balanced Power Plan again (this power plan's Powercfg.exe tables has been modified to allow the CPU to still be controlled by the OS thru AMD's Cool & Quiet) & reset the PERFINCTHRESHOLD & PERFDECTHRESHOLD parameters (CPU usage parameters that instruct the OS to instruct AMD's Cool & Quiet\TurboCore to ramp up\down CPU power\frequency) from 40\30 to 30\25 (lowered the adjustment threshold settings so that the OS will instruct Cool & Quiet to allow TurboCore to load up the CPU once the usage avg exceeds >30%...as long as the CPU temps stay below the TDP threshold (80*C) & will shut down TurboCore to allow Cool & Quiet to throttle CPU power\frequency if the CPU temps exceed the TDP limit OR if the CPU avg core usage recedes <25%) due to thought that the 40\30 setting range may be still causing CPU power\frequency to be oscillated due to CPU core usage dipping back below the 40% upper range in which Cool & Quiet might be trying to throttle CPU on a percentage basis when usage falls in between the 2 control points of 40\30 (which I have witnessed happening from time to time while playing). To test these settings properly I also went in the WBPP advanced settings & lowered the min processor power % setting from 75% to 50% (at this setting Cool & Quiet will throttle the CPU to the lowest power\frequency table setting @ 2.2 Ghz so any further lowering of the min processor % setting in the WBPP advanced settings is useless).
Ran the game & I immediately noticed that I had hit a setting curve that really made a difference on the Ryzen 7 1800X's performance. Evidently the CPU had been throttling but it isn't throttling now......CPU is running very stable @ 3.7 Ghz on all 8 CPU cores w\o fluctuation w\ TurboCore applying full power @ 1.45v-1.5v & CPU operating temps never dropping below 49*C at any time. Most of the time the CPU core temps held between 52*C-58*C (prior setting @ 40\30 CPU operating temps ranged between 44*C-52*C w\ CPU clocks bounce between 3.2Ghz-3.7Ghz) so I now know that the CPU is really running at full power now. The game ran much, much better than it has for some time so I've got some more performance to enjoy now! Played for approx 35-40 mins w\ all going good.......but then a screen freeze\pause occurred right as I had leveled out into level flight but the freeze duration was much shorter than the others so I think I'm starting to gain on it but time will tell.
Ongoing......................
FYI........................
:salute
-
Update:
Just got done playing AHIII Dx11 vers again & all was going very well w\ box performing subperbly w\o a screen freeze\pause then once I entered into landing glide path\angle w\ me ole Spitty (leveled out w\o a lot of movement) I had a screen freeze occur............
This is now 2 times in which all was looking good as long as there was a lot of movement, control input, etc that kept the CPU core usage above 75% & up but as soon as I went into level flight w\ CPU core usage dropping below 65% is when the screen freeze happened. GPU tach on the Fury X was pegged out thruout so the GPU was running flat out at full clocks @ 1050\500 mem (stock GPU boost clocks\mem clocks for Fury X\Fiji GPU). GPU usage% never got even close to 90% usage (mostly hovering in the 70's-80's) so what I'm seeing may be a function of something going on within this Fury X's Fiji GPU at the vUEFI\driver level.........maybe related to some type of GPU power fluctuation anomaly when changing power states when throttling back on power but not GPU clock speed. Read speculation here.................
Wished I had access to this Fury X's vUEFI to check into this...............
Check out this MSI AB graph's GPU frametime graph line.............that is the best frametime graph line that I have ever witnessed coming from this Fury X........the GPU wasn't missing any graphics frames rendering\displaying & was VERY steady doing it all.
FYI..........................
:salute
PS---It just dawned on me that this issue on my box just may be a symptom of this Fury X hitting its practical operational limit at which these kinds of anomalies may start occurring when running under Dx11 breaking the graphics rendering work into pieces to take advantage of this GPU's ACE's.....thinking parallel multiprocessing issue in which 1 ACE unit may be a little slow to get it's piece of the work done in time relative to the others. This is a complex GPU...............
Just a hunch..............
:salute
-
deleted
-
another approach would be to look how skuzzy configures his boxes, bios settings, drivers, services etc and work from there?
-
another approach would be to look how skuzzy configures his boxes, bios settings, drivers, services etc and work from there?
Check out page 3, reply #37 of this thread...................
:salute
-
I've seen that post my point is that skuzzy probably runs a much cleaner system than the average joe and that may be why he can't reproduce the stutter?
-
I've seen that post my point is that skuzzy probably runs a much cleaner system than the average joe and that may be why he can't reproduce the stutter?
There's many of us who run quite a clean system and still get pauses.
Skuzzy once revealed the method he installs Windows on his personal systems but I don't know if that's how the HTC computers are built. Anyway, his idea is to tailor the installation media according to the actual system. A standard Windows package contains generic drivers for nearly all possible components so that the system can be booted for dedicated driver installation. However, that affects mostly boot times when the system fumbles through the repository to find the right drivers for each present component.
-
My personal computer is configured very differently. I stick to the defaults on our work systems, but also cut down unnecessary background processes. My work computer is not as clean as it could be, but it also does not have much installed on it.
There are so many intrusive applications out there today.
There is one major change I do make with our systems. We run Windows 7 Pro, (HiTech has one Windows 10 system) and I turn off Aero and revert to the classic Windows desktop. This frees up some DirectX resources.
-
Update:
Worked w\ CPU as follows:
Enabled High Performance Power Plan so CPU will run at full clocks (even though AMD Cool & Quiet is still enabled in UEFI) then ran the game......played for approx 25 mins w\ steady CPu clocks @ 3.7 Ghz.........but got a screen freeze to still occur.
Got an idea............
Went & enabled the Balanced Power Plan again (this power plan's Powercfg.exe tables has been modified to allow the CPU to still be controlled by the OS thru AMD's Cool & Quiet) & reset the PERFINCTHRESHOLD & PERFDECTHRESHOLD parameters (CPU usage parameters that instruct the OS to instruct AMD's Cool & Quiet\TurboCore to ramp up\down CPU power\frequency) from 40\30 to 30\25 (lowered the adjustment threshold settings so that the OS will instruct Cool & Quiet to allow TurboCore to load up the CPU once the usage avg exceeds >30%...as long as the CPU temps stay below the TDP threshold (80*C) & will shut down TurboCore to allow Cool & Quiet to throttle CPU power\frequency if the CPU temps exceed the TDP limit OR if the CPU avg core usage recedes <25%) due to thought that the 40\30 setting range may be still causing CPU power\frequency to be oscillated due to CPU core usage dipping back below the 40% upper range in which Cool & Quiet might be trying to throttle CPU on a percentage basis when usage falls in between the 2 control points of 40\30 (which I have witnessed happening from time to time while playing). To test these settings properly I also went in the WBPP advanced settings & lowered the min processor power % setting from 75% to 50% (at this setting Cool & Quiet will throttle the CPU to the lowest power\frequency table setting @ 2.2 Ghz so any further lowering of the min processor % setting in the WBPP advanced settings is useless).
Ran the game & I immediately noticed that I had hit a setting curve that really made a difference on the Ryzen 7 1800X's performance. Evidently the CPU had been throttling but it isn't throttling now......CPU is running very stable @ 3.7 Ghz on all 8 CPU cores w\o fluctuation w\ TurboCore applying full power @ 1.45v-1.5v & CPU operating temps never dropping below 49*C at any time. Most of the time the CPU core temps held between 52*C-58*C (prior setting @ 40\30 CPU operating temps ranged between 44*C-52*C w\ CPU clocks bounce between 3.2Ghz-3.7Ghz) so I now know that the CPU is really running at full power now. The game ran much, much better than it has for some time so I've got some more performance to enjoy now! Played for approx 35-40 mins w\ all going good.......but then a screen freeze\pause occurred right as I had leveled out into level flight but the freeze duration was much shorter than the others so I think I'm starting to gain on it but time will tell.
Ongoing......................
FYI........................
:salute
Update:
Still working this issue thru the CPU side, but since the initial work as laid out above I have only witnessed 1 screen freeze\pause occur from that time until now so this is a good sign of making some progress......on my end of this subject.
I did find out that when using the Windows TM (Task Manager) running in the foreground (set to "Always Stay on Top") while AHIII Dx11 version was running (used this to monitor my CPU & Ethernet operations in real time), AHIII Dx11 would run in Windowed Mode on my monitor w\o any issues at all.......and run w\o a screen freeze\pause occurring......hhhmmmm......
Or maybe AHIII Dx11 APPEARS to be running in Windowed Mode but it isn't...........but I definitely witnessed AHIII Dx11 game running w\o any issues or any lack of game functionality within a Windows pane w\ Windows TM open & set to Always Stay on Top which clearly indicates that Windows is in the foreground w\ AHIII running within it........
Curious now......just how does the VR code actually function in the game concerning display output? Does VR run in full screen mode (Windows relegated to the background) or does it run in Windowed Mode (Windows running in the foreground) but w\o the pane being visual when displayed thru the headset?
Interesting as it was my understanding that AHIII wouldn't run in Windowed Mode, only in full screen........maybe I misunderstood...........
Another item of interest to read up on concerning VR...................
Anyway the TM graphs did show that my Ethernet was running very smooth & stable w\ an occasional spike every now & then but not very high or long in duration so this was a good thing & confirmed the work that a local CenturyLink tech (who was a gamer himself as I found out from conversation w\ him when this tech came out to the house on a service call placed by Mrs Pudgie during a time when CenturyLink was having line issues & was installing line\system upgrades where found warranted) was indeed working (he told me that he had made some changes somewhere in the CenturyLink system to enhance the ADSL service to my line after he saw my setup & told me to call him direct if we had any more service related issues) along w\ me rerouting a spare phone line that wasn't being used to connect Mrs. Pudgie's AIO & got it off the ADSL line so this was good news. The CPU graphs also verified that the latest Powercfg CPU power control setting changes that I made to the WBPP (Windows Balanced Power Plan) were maintaining the CPU constant at full CPU power\clocks while under running game load & would only clock down when the game was exited back out to the desktop so this is now handled.
The new Sunix USB-to-PCI-E add-in card should be here tomorrow & will continue to monitor my box afterwards.
Ongoing..................
:salute
-
I've seen other game recommending to run fullscreen windowed for best performance
-
Update:
After working some other items it's getting better...............
Went on HWINFO web site, entered the forum there & read thru the BBS. Learned some things about this piece of software that also may have had some small part to play w\ the screen pause\freezes..........
1. Shut down all HWINFO32 settings that were specifically for Nvidia graphics cards so HWINFO32 wouldn't try to be using these w\ my Radeon. This was done.
2. Found that AMD has issues w\ their own monitoring ADL API that can cause issues w\ HWINFO32 reading GPU temps & usage levels on AMD\ATI graphics cards. Recommended to disable this & use HWINFO32's own direct-GPU low-level access API for stability. This was done.
3. Found that there was a newer version (5.56) that had improved sensor monitoring capabilities & stability improvements w\ AMD\ATI graphics cards, had improved AMD Ryzen CPU support & were updated to support AMD Threadripper CPU's\X399 chipsets. Updated to 5.56 & reset all settings as prior in 5.50.
Went up in AHIII Dx11 & played around for a while & noted that the game ran very well w\ so far nary a screen freeze\pause........will continue to test this out to verify. From prior results this may be a placebo effect but so far, so good.
Ongoing...................... .....
:salute
-
I've seen other game recommending to run fullscreen windowed for best performance
That might be just a trick to reduce the pixel count of the actual game. Less pixels equals to less load for the system. The frames and Taskbar can easily take some 10% off the active screen area. I don't know if pixel count correlates directly with frame rates, anyway it can be enough to take you above a certain threshold like 30 FPS which can be considered somewhat of a minimum for fluent playability.
Take the above with a grain of salt, it's merely logical thinking instead of hard facts and in-depth knowledge.
-
Update:
Still working this issue thru the CPU side, but since the initial work as laid out above I have only witnessed 1 screen freeze\pause occur from that time until now so this is a good sign of making some progress......on my end of this subject.
I did find out that when using the Windows TM (Task Manager) running in the foreground (set to "Always Stay on Top") while AHIII Dx11 version was running (used this to monitor my CPU & Ethernet operations in real time), AHIII Dx11 would run in Windowed Mode on my monitor w\o any issues at all.......and run w\o a screen freeze\pause occurring......hhhmmmm......
Or maybe AHIII Dx11 APPEARS to be running in Windowed Mode but it isn't...........but I definitely witnessed AHIII Dx11 game running w\o any issues or any lack of game functionality within a Windows pane w\ Windows TM open & set to Always Stay on Top which clearly indicates that Windows is in the foreground w\ AHIII running within it........
Curious now......just how does the VR code actually function in the game concerning display output? Does VR run in full screen mode (Windows relegated to the background) or does it run in Windowed Mode (Windows running in the foreground) but w\o the pane being visual when displayed thru the headset?
Interesting as it was my understanding that AHIII wouldn't run in Windowed Mode, only in full screen........maybe I misunderstood...........
Another item of interest to read up on concerning VR...................
Anyway the TM graphs did show that my Ethernet was running very smooth & stable w\ an occasional spike every now & then but not very high or long in duration so this was a good thing & confirmed the work that a local CenturyLink tech (who was a gamer himself as I found out from conversation w\ him when this tech came out to the house on a service call placed by Mrs Pudgie during a time when CenturyLink was having line issues & was installing line\system upgrades where found warranted) was indeed working (he told me that he had made some changes somewhere in the CenturyLink system to enhance the ADSL service to my line after he saw my setup & told me to call him direct if we had any more service related issues) along w\ me rerouting a spare phone line that wasn't being used to connect Mrs. Pudgie's AIO & got it off the ADSL line so this was good news. The CPU graphs also verified that the latest Powercfg CPU power control setting changes that I made to the WBPP (Windows Balanced Power Plan) were maintaining the CPU constant at full CPU power\clocks while under running game load & would only clock down when the game was exited back out to the desktop so this is now handled.
The new Sunix USB-to-PCI-E add-in card should be here tomorrow & will continue to monitor my box afterwards.
Ongoing..................
:salute
I cant remember when the last time I had a stutter or micro freeze, in VR. Not sure why that is, as it runs the Headset and a "windowed" mirror screen also. Maybe its because the "TRUE Display" is running windowed as per your observations with reg. AH3? The Headset isnt recognized as a "Display" device so...could be?
-
Actually, running windowed (frame around the application), in DirectX, imposes a lot more overhead.
-
Actually, running windowed (frame around the application), in DirectX, imposes a lot more overhead.
Makes me glad I added the salt clause. :cheers:
-
Update:
After working thru all this on my box I have actually made some minor progress.
As for resolving the screen pause\freeze issue completely I haven't, but from this work I have successfully affected the frequency (slowed them down) at which they occur & have somewhat narrowed the parameters in which to expect 1 to occur.
Since doing all this work it has demonstrated that the CPU processing efficiency will affect their occurrence.....the more efficient the CPU is at processing instructions (which also includes ISR's & DPC's) the less these will show up as there will be less chance of a buffer underrun happening if these are processed as fast as the CPU can process them & get the data in the L3\system mem cache to reduce the amount of time that the CPU isn't handling the other tasks that also need to be done. This doesn't explain the actual cause but can certainly reduce the issue & at the same time increase system productivity.....which is a good thing.
The next item is that after doing all this I have seen that the pattern of these screen pauses\freezes occurring has narrowed somewhat in that I have noted that when playing the game now, as long as the gameplay sets up scenarios that call for my box to increase performance due to increased work loads, I haven't witnessed a screen pause\freeze to occur & as long as the high work loads remain which maintain the high CPU\GPU work loads I haven't witnessed a screen freeze\pause occur. It is only now during the transition time from high CPU\GPU work loads to lower CPU\GPU work loads is when I have noted screen pauses\freezes to occur, not all the time do they appear during this slowing down period but the pattern does show the odds of 1 occurring during this particular time in gameplay is very high relative to any other time. My MSI AB graphs have consistently captured this happening but in times past the CPU side (CPU usage % clearly drops off on the SINGLE heavily loaded CPU core ONLY that the game threads are being processed on when the GPU clocks & FPS drop & GPU frametime spikes up then ramps back up when the GPU side does on recovery) didn't show itself as clear as it is now. I do know that AMD's Cool & Quiet isn't the cause as they still occur regardless of whether this is enabled or disabled in UEFI.
The game doesn't stop running, sound is never interrupted, control input is good, only the screen (video) is affected. Latency Mon is showing the only drivers to be showing any significant ISR's\DPC's are the Windows Driver Mode Framework Runtime(wdf01000.sys), Directx Graphics Kernel (dxgkrnl.sys) showing no ISR's but several DPC's & the Windows NT Kernel & System--the heart of Windows OS-- (ntoskrnl.exe) to a lesser degree showing no ISR's but a few DPC's. These are the top 3 drivers that consistently show the highest instances of ISR's\DPC's....everything else is FAR less.
I loaded the AMD Crimson 17.8.1 drivers specifically due to the release notes stating that AMD had fixed intermittent crashing in GTA V.....this game exhibits the exact same graphics screen pausing\freezing as AHIII Dx11 is showing in the exact same manner so I was hoping that this "GTA V fix" would resolve this in AHIII.....and as happened in times past.......appeared to had done so but they eventually came back. There is a tool developed to access vUEFI's for AMD Polaris & Vega cards called WattTool that can be used to make changes but I haven't ran into anything to allow access to AMD Fiji cards yet.
In closing I have a good sense of what is not causing these from a program standpoint. Looking thru the Services side of Windows I have reset a fair amount of these services to "Manual" once I checked them for any dependencies on other services or other services needing them to be active & all is operating very well w\o issues & Windows still checks out as clean so whatever the cause is IMHO it has to be something somewhere in the graphics interaction pipeline between the CPU thru to the GPU w\ anything else going on being an influencer\aggravator to the actual cause. In TM my box shows to have anywhere from 115 to 125 processes running in Windows 10 Home so I will need to be doing a LOT of Bing'ing my Windows 10 services to get more indepth detail on which ones that I can safely disable to lower this some but to date I have found no ill effects from all these processes running so far that I can tell.
Gonna move on to other things for now. Will revisit this after some more study time.
:salute
-
Looks like some of you may be experiencing this on top of everything else.
A Windows 10 update is causing stutters and pauses in games.
https://www.onmsft.com/news/microsoft-finally-confirms-game-stuttering-problems-in-windows-10-creators-update-says-fixes-are-coming
-
Looks like some of you may be experiencing this on top of everything else.
A Windows 10 update is causing stutters and pauses in games.
https://www.onmsft.com/news/microsoft-finally-confirms-game-stuttering-problems-in-windows-10-creators-update-says-fixes-are-coming
This appears to be exactly what is impacting me.
http://bbs.hitechcreations.com/smf/index.php/topic,388923.15.html
Yesterday I had about 2 hours to get on line and play, however, when I got on, the game became unplayable. I checked and an update was running. The update ran for over an hour and in the end I just gave up waiting.
I guess that from now on I will try to turn on my game PC 2 to 3 hours before I get on AH3 (it stays off for weeks at a time) and hope that that takes care of the issue for me. :old:
BTW: Great find on article and thanks for posting. :aok
-
Also, take note when a pause/long stutter happens and see if the clipboard is up at the time of the occurrence.
-
SysError here is your fix for that problem with Windows 10 updates coming in when you want to play.
When you enter the game if the network connection on the right side of the Arena shows a very high number do this:
Exit the game.
Press Control – Alt- Delete
Go to Task Manager
Look in the right column at network % usage
Scroll down to the item which item is using the network (it will be a windows function)
Right click select END TASK you will get a popup box (make sure to put a check the box at the bottom in this box first) then click OK
Wait for network to go to 0%
Go play game
The process will restart the next time you start the computer…
Restart the computer after you are done playing and let it run then.
-
Rebel28, can you confirm that the ended process will wait until the next startup? For what I've encountered with the dreaded Windows Update issue in Win7, the svchost.exe process hosting the service wuauserv (Windows Update) restarted every few minutes. Win10 may work differently here and I have professional interest about knowing if it's does.
-
If you don't check the box in the popup that says to dump the data already downloaded it will restart immediately. Checking this box will stop the process until next restart.
I have been doing this since I first found the information on a windows problem and fix site.
It has been so long ago I don't even remember which site it was on.
Or I am just getting to the age it's hard to remember what was for dinner last night.. :)
-
Thanks, there's a ton of information about Win10 I haven't yet familiarized yet. :cheers:
Mmm... dinner...
-
Thanks, there's a ton of information about Win10 I haven't yet familiarized yet. :cheers:
Mmm... dinner...
Wait, what were we talking about? Dinner? What we having? I will buy if You will fly :x Oh,nevermind, I forgot I just ate dinner. :uhoh Was wondering why my hands were greasy and had that napkin stuffed under neck of my shirt, Oh well :cheers:
-
Been flying DX11 for the last few days, with no stutters. Anyone else seen this?? :rock
-
NO :furious Then again I am using it with VR :uhoh Maybe light at the end of the tunnel on that problem though :rock
-
Been flying DX11 for the last few days, with no stutters. Anyone else seen this?? :rock
I don't get many stutters, but the hard freezing (lasting from 1-2 seconds) are still there.
Coogan
-
I'm still getting them too.
-
I don't get many stutters, but the hard freezing (lasting from 1-2 seconds) are still there.
Coogan
Same here.
:salute
-
:(
started getting them again the other night.
-
:furious Just HAD TO BRING IT UP... :D Wasnt your fault, OR WAS IT :uhoh :x