Fulqrum Publishing Home   |   Register   |   Today Posts   |   Members   |   UserCP   |   Calendar   |   Search   |   FAQ

Go Back   Official Fulqrum Publishing forum > Fulqrum Publishing > IL-2 Sturmovik: Cliffs of Dover > Technical threads > Performance threads

Performance threads All discussions about CoD performnce

Reply
 
Thread Tools Display Modes
  #1  
Old 05-02-2011, 03:25 AM
TUSA/TX-Gunslinger's Avatar
TUSA/TX-Gunslinger TUSA/TX-Gunslinger is offline
Approved Member
 
Join Date: Oct 2007
Location: Austin Texas
Posts: 195
Default Testing results beta 1.00.14305 complete

I've done a lot of controlled "The Black Death" track replays, and since it's Monday in Russia - I thought I'd post my findings.

Here are graphs of 6 successive track playbacks attempting to isolate the cause of random stuttering and pausing on some track playbacks but not others. The following two examples iterate ProcessingAffinityMask and show the performance of CPU/GPU syncronized with other measurements and Fraps results.

All my settings and system configuration is listed on these first two examples which display 22 minutes of data overall - each TBD track is 3 mins 40 secs in duration:

Note: My HD5870 GPU is operating at maximum clock during loading from CoD track playback






Note the playbacks in which the fps was 0 or lower than 10. Those are track playbacks with significant pausing and stuttering.

Now here's a couple sets of measurements over two different tracks - at higher time resolution so you can see the relationship between GPU and CPU loading during a stutter/pause and a track with good performance - i.e. no stutter or pausing

First the smooth track playback, note that GPU loading (purple) never drops lower than 50% during the track.



Now a playback which had significant pause (like 2 seconds). Note that during the stutter the CPU (yellow) drops to 0 first - then the GPU (purple) drops to 0.



No matter what Catalyst setting or CoD setting I changed - the stuttering and pausing continued randomly throughout testing. Many times, I thought one setting or the other had improved it - but follow on testing produced more stutter tracks.

In summary - It's the CPU not the GPU that producing the stutter and pausing.

As has been reported many times - the AA only works in two modes - OFF and 1X-2X-4X-8X all producing the same graphic output. Strangley, I found performance better at higher settings even though the screen output was the same.



S!

Gunny
__________________
Intel i7-3930K @ 4.00 MHz - ASUS Rampage IV
EVGA 3072MB VRAM GTX 580
16GB RAM - Windows 7/64
Warthog and U2Nxt Cougar under t.a.r.g.e.t

Last edited by TUSA/TX-Gunslinger; 05-02-2011 at 04:47 AM.
Reply With Quote
  #2  
Old 05-02-2011, 12:57 PM
kyletiernan kyletiernan is offline
Approved Member
 
Join Date: Oct 2010
Posts: 59
Default

Nice work, saved the devs some work. Hopefully they read this and make some changes.
Reply With Quote
  #3  
Old 05-02-2011, 01:34 PM
Phazon Phazon is offline
Approved Member
 
Join Date: Apr 2011
Posts: 270
Default

Nice work. I thought the big pauses were from the CPU being overloaded but it looks like otherway around - the game drops the ball and stops feeding it.
Reply With Quote
  #4  
Old 05-02-2011, 01:45 PM
TUSA/TX-Gunslinger's Avatar
TUSA/TX-Gunslinger TUSA/TX-Gunslinger is offline
Approved Member
 
Join Date: Oct 2007
Location: Austin Texas
Posts: 195
Default

Thanks for the kind words. It took me days to figure this out, due to the randomness of runs. At one point I thought it was Tessellation, at another I thought it was ATITraytools interacting with the program, at one point I thought it was ProcessAffinity settings. All false leads

When I finally by the weekend, when I starting looking at the CPU/GPU interactions during stutters - I finally got it. It took all those plots and graphs to prove it however.

Yes Phazon, that's exactly how it seems to me - the CPU gets starved for info and stops - then the GPU follows. In many runs you'll see the CPU start to come down in load - but it picks back up before the GPU is effected.

I wanted to put this out here to stop folks from running out and buying video cards right now. By all means, wait until it all stabilizes then see what you need.

Last thing: As you can see in the first series of graphs, my HD5870 is running at max clocks just fine. One of the interesting things that's occuring apparantely is the HD6000 series cards are not "clocking up". So HD5000's are operating one way - while HD6000's are operating in another.

S!

Gunny
__________________
Intel i7-3930K @ 4.00 MHz - ASUS Rampage IV
EVGA 3072MB VRAM GTX 580
16GB RAM - Windows 7/64
Warthog and U2Nxt Cougar under t.a.r.g.e.t

Last edited by TUSA/TX-Gunslinger; 05-02-2011 at 01:58 PM.
Reply With Quote
  #5  
Old 05-02-2011, 02:03 PM
Sauf Sauf is offline
Approved Member
 
Join Date: Oct 2010
Posts: 436
Default

Great work Gunslinger, only downside is I think Russia is on 5 days off for May day holiday.
Reply With Quote
  #6  
Old 05-02-2011, 02:12 PM
Orpheus Orpheus is offline
Approved Member
 
Join Date: Mar 2011
Posts: 235
Default

Quote:
Originally Posted by TUSA/TX-Gunslinger View Post
Last thing: As you can see in the first series of graphs, my HD5870 is running at max clocks just fine. One of the interesting things that's occuring apparantely is the HD6000 series cards are not "clocking up". So HD5000's are operating one way - while HD6000's are operating in another.
Good work on this testing dude. Just so you know the ATI underclocking issue has been solved:

http://forum.1cpublishing.eu/showpos...&postcount=289

It's the Ubi splash video that plays when the EU edition starts up (RU version doesn't have the Ubi splash so it's an EU problem only, afaik). With GPU-Z open at startup, you'll see normal clock speeds until that video plays - the vid causes the GPU clock to lock to the UVD video setting (usually 400mhz) and ATI powerplay won't detect the change, leaving us stuck at video clock speeds.

Delete or rename the splash.wmv as described in the linked post and any cards suffering this issue should clock normally.
Reply With Quote
  #7  
Old 05-02-2011, 02:13 PM
Buchon Buchon is offline
Approved Member
 
Join Date: Apr 2011
Posts: 437
Default

I found that the game still trashing the HDD, even having free RAM to use, and that event cause shuttering.

If the game is not limited in the use of RAM and detects the available resources, and this objects are previously loaded in RAM, the HDD trashing shutters will disappears.

Maybe is the search of this resources in the HDD what is causing this CPU hold back, or just is another source of shuttering different.
Reply With Quote
  #8  
Old 05-02-2011, 02:14 PM
SUP_Trok SUP_Trok is offline
Approved Member
 
Join Date: Apr 2010
Posts: 35
Default

Very good work!!
Reply With Quote
  #9  
Old 05-02-2011, 02:35 PM
TUSA/TX-Gunslinger's Avatar
TUSA/TX-Gunslinger TUSA/TX-Gunslinger is offline
Approved Member
 
Join Date: Oct 2007
Location: Austin Texas
Posts: 195
Default

Quote:
Originally Posted by Buchon View Post
I found that the game still trashing the HDD, even having free RAM to use, and that event cause shuttering.

If the game is not limited in the use of RAM and detects the available resources, and this objects are previously loaded in RAM, the HDD trashing shutters will disappears.

Maybe is the search of this resources in the HDD what is causing this CPU hold back, or just is another source of shuttering different.
Well, I looked hard for that. By doing sequential track playback runs - where the track is already in RAM after the first playback - you figure your getting around the disk access issue.

It actually looks to me (if I had to be forced to guess) like a broken thread. i.e - one of the many processes that runs threaded, just had an error and stops. Then the process has to go and find something to "do".

In short after several hundred runs this week, I saw no evidence of storage access issues.

S!

Gunny
__________________
Intel i7-3930K @ 4.00 MHz - ASUS Rampage IV
EVGA 3072MB VRAM GTX 580
16GB RAM - Windows 7/64
Warthog and U2Nxt Cougar under t.a.r.g.e.t
Reply With Quote
  #10  
Old 05-02-2011, 03:04 PM
Buchon Buchon is offline
Approved Member
 
Join Date: Apr 2011
Posts: 437
Default

Quote:
Originally Posted by TUSA/TX-Gunslinger View Post
Well, I looked hard for that. By doing sequential track playback runs - where the track is already in RAM after the first playback - you figure your getting around the disk access issue.

It actually looks to me (if I had to be forced to guess) like a broken thread. i.e - one of the many processes that runs threaded, just had an error and stops. Then the process has to go and find something to "do".

In short after several hundred runs this week, I saw no evidence of storage access issues.

S!

Gunny
So there two sources of shuttering.

Im talking about the first load in RAM, for example flying in "free fly mode" when you are approaching to a city the game shutters searching in the HDD some thing, a house or something, when it is already in RAM there no shutter flying the same zone.

But there free RAM, why is not this loaded already ?

About the strange issue that there better performance with AA in x8 than in x4.

That is a ATI issue, they have better performance in x8 than x4, even if it is not working properly, dont know why
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 09:40 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 2007 Fulqrum Publishing. All rights reserved.