SAAB340

3866 C18 will be the better option there no doubt.. Remember that C18 and C10 is the timing. Latency and MHz is what maters. Timing x 2000 / MHz = Latency in ns. Your two examples has very similar latency. 18x2000/3866=9.3ns and 10x2000/2133=9.4ns. Lower latency is better and higher MHz is better. Both give better FPS. I'd try to keep the latency under 10ns. The best most expensive modules will stop at about 7.5ns. When it comes to RAM pay a little bit extra for large improvements in latency and MHz. But bang for the buck goes out of the window at the higher end for very minor improvements. Minor real life FPS improvements that is.

Yes. Higher frequency and tighter timings are beter. Westman has shown that as well in many great FSXmark11 tests . I posted quite a few results with different RAM speeds/timings when I built my Skylake build soon a year ago I think. That's why Skylake with its good memorycontroller, IPC and overclockability is actually a worth while upgrade. Kaby lake will probably as well unless you're already on a Skylake. My SB-E only manages an overclock of 4.3GHz whilst the Skylake does 4.7. When you factor that and the RAM in the Skylake system gives me 45% higher FPS. That is a very notable improvement. Katy Lake however won't introduce a much faster DDR4 memorycontroler as Skylake did. History shows that the IPC improvements will be very minor. The only variable left is overclockability, where as usual early indications are promising. Physics normally puts a damper on our hopes though. (Wouldn't surprise me if I still get a 7700K to play with though...=) Looking forward to seeing what Westman kan do with it when its released. I still prefer the SB-E system for photo scenery though as the extra cores still loads the ground textures faster despite the improvement in Single Thread performance that gives the much higher FPS. But boy does it irritate me every time I can't maintain my locked smooth 30FPS on the SB-E nowadays when I know I don't get that on the Skylake in the same situation.

Thanks, Found this one I did a while ago that I don't think I've posted. To show the impact of RAM on my SandyBridge-E and Skylake.

The answer is that there is no CPU with 4LPs per core you can run FSX or P3D on now. Just in case someone is trying to follow the conversation.

Given what you said: To me changing config settings and testing to figure out what is really happening is reverse engineering. It might not be the 100% correct meaning of the word (English is not my first language). Nothing bad implied. I still can't understand what CPU you mean we can use for flightsim that has 4 threads per core? The only Xeon with 4 threads per core I'm aware of is the Xeon Phi. Whilst its an x86 architecture you can't just run flightsim on it. What have I missed?

Florida x4 was updated a long time ago if that is what you are waiting for

You kinda lost me there. What CPUs we use FSX on have four logcal cores on each physical core? AM=113 on a dual core with hyperthreading will just assign 1 core. Not a good idea. The sim might have more than 50 threads but most of them generate very little CPU load. The treads that generate any notable CPU load are: 1. The main game thread. It will be assigned the 'first' CPU core assigned with the Afinitymask. If you are just bottlenecked by your CPU this will generate a full core load. 2. Texture and terrain loaders. These help loading in the terrain, autogen and ground textures. If you don't have any assigned the main game thread has to do all of that. How many that are created depends on your affinitymask and how many logical CPU cores you have. The amount of Texture and terrain loading threads spawned is the amount of assigned cores in the affinitymask (that fit in the actual logical cores you have) -1. These have a very bursty load. If you are stationary nothing new has to be loaded so they will generate no load. Fly fast and they will generate more load. However every minute the lighting of the ground textures has to be updated so they peak towards a full core load every minute regardless of how fast you fly. The higher LOD setting and the higher resolution scenery/terrain mesh you have the more core load they will generate. ​3. A thread that reads almost all information needed from your hard drive for the simulator. (Sound files seem to be read off the harddrive by the main thread and a few other files are also accessed by the main thread, hence triggering a sound file might cause a stutter if you don't have an SSD). The load on this thread is very variable and can go from nothing to filling a full core load depending on what scenery you have active. This thread does not get any core assigned by the affinitymask in the cfg. Windows will decide on affinity for it when you start the simulator. 4. A sound thread. This generates a small CPU load and is assigned affinity by Windows and not the affinitymask in the cfg. The thread is killed every time the simulator is not the active window any more. And a new sound thread is spawned when the simulator is once again selected as the active window. This new thread will once again get affinity assigned by Windows. But it might be different compared to what it was assigned before. 5. A debug thread. Not a lot of CPU load but more than any of the other 50+ threads that are left. Windows sheduler doesn't have to adhere to the assigned affinity. It uses it as a guide but most of the time the Main game thread and the texture and terrain loading theads are executed on the cores they have been assigned. But sometimes even they don't. The other threads are regularly being executed on cores outside the affinity assigned to them by Windows. Sorry for all the technical hijack of the tread OP. Fun to reverse engineer the sim right? :smile: I'm just talking about FSX. Not played around with FSX:SE or P3D.

Remember that Broadwell is not in the graph so the actual IPC improvement going 2 generations from Haswell to Skylake is minor. But when you also factor in the move to DDR4 it gives a lot more performance improvement. And the memorycontroller in Skylake handles way higher DDR4 speeds than 2133. IPC improvements Skylake to Kabylake will be very minor Probably less than SanyBridge to IvyBridge. If you run your CPU at stock speed 7700K will be a bit faster but overclockability might be what determines if it is any improvement as an upgrade over 6700K. If you're upgrading from a previous platform I suspect 7700K will be the best option. But suspect upgrading from 6700K is not going to be worth it. Unless its a very good overclocker.

You mean in a well balanced system where the CPU is the bottleneck... :wink: Different CPU architectures and RAM speeds also affect the FPS. Here is how much they all perform relative to each other in FSX when you are CPU limited.

Yeah, I did use the old 1.2 installer. So I guess it could be that. It did work fine installing V3 Alabama, Arkansas and Tennessee withoutit prompting me for the registration more than once using the same 1.2 installer though... I'll get in touch with MSE about the black stripe. It's I obviously in the data that generates the bgls. It is confined to a thin stripe in MO_898.bgl

FSX makes good use of multi core and HyperTreading but when you get past 3 cores it is only improving ground texture loading. I've just been playing around a bit with my 6700K recently and without HT activated (with appropriate AM) I find it horrible for photo scenery. You can't fly very fast with a high LOD without getting blurries. With HT on (and appropriate AM) it is a lot better but still not as good for ground texture loading as my 6 core SandyBridge-E with HT on. That is despite the Skylake having a higher overclock than the SandyBridge-E. But when it comes to FPS the Skylake is very noticible better with its beter architecture, DDR4 and higher overclock. (Give me Skylake-E soon please Intel...) AM=85 is the FSX default for a quad core HTon. That's what you get if you don't put anything in the .cfg. For a quad core I find AM=241 is the best all-round AM with HTon whilst AM=249 works even better with some photoscenery but has the potential to not work so well depending on if you get any other CPU intensive activity running. (UK photoscenery with treescapes for example generates high CPU load on the FSX thread that loads pretty much everything that is read from your harddrives). I would also imagine any Wx software that generates a lot of cpu load at times injecting Wx might not work that great with AM=249. If you activate HT and use AM=84 it is the equivalent of HToff AM=14.

Here is a screenshot of what I am seeing. Do you have the same or is it my install that is corrupt?

I've just downloaded and installed MO today and the problem is still there. I've also noticed a thin but long stripe of just black ground textures east of KSGF. Do you have the same? (Sorry, can't take a screenshot right now which would have helped but it is very obvious for me when I take off from KSGF and head east.)

Is the last tile by any chance called AZ_729 and you have 670 bgls in total? This is the pictorial version with every X being a bgl tile: XXXXXXXXXXXXXXXXXXXXXXXX (bgl 4- 27) XXXXXXXXXXXXXXXXXXXXXXXX (bgl 31- 54) XXXXXXXXXXXXXXXXXXXXXXXX (bgl 58- 81) XXXXXXXXXXXXXXXXXXXXXXXX (bgl 85-108) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 109-135) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 136-162) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 163-189) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 190-216) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 217-243) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 244-270) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 271-297) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 298-324) XXXXXXXXXXXXXXXXXXXXXXXXX (bgl 327-351) XXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 353-378) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 379-405) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 406-432) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 433-459) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 460-486) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 487-513) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 514-540) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 541-567) XXXXXXXXXXXXXXXXXXXXXXXXXXX (bgl 568-594) XXXXXXXXXXXXXXXXXXXXXXXXX (bgl 597-621) XXXXXXXXXXXXXXXXXXXXX (bgl 628-648) XXXXXXXXXXXXXXXXXX (bgl 658-675) XXXXXXXXXXXXXXX (bgl 688-702) XXXXXXXXXXXX (bgl 718-729) Does this look like Arizona squeezed at the sides? :smile:

The assumption that all bgl's are supposed to be consecutive is an easy one to make but it is wrong. I'll quote my own answer to a similar question in another thread. Looking at the numbers of assumed 'missing' tiles you have there are consistent with Arizona being 27 tiles wide and the shape of the state having a straight N and E border, a chunk missing in the top NW corner, the W border having a chunk going in to the state somewhere about in the middle and the southern border tapering off towards the N a little bit more than half of the state. If you are still worried, just load up a flight at for example KFLG, select outside top down view and zoom out until you see the whole state. Any tiles missing inside the state will easily show up.

Yes that is normal. I've only just got around to install my V3 scenery and have now started to analyse the changes. They have obviously developed a new naming scheme for the bgl files. Previously the bgls were named xxx_letter_number.bgl where the letter were north-south coordinates and the numbers were west-east coordinates in a grid over the state. Now they just use xxx_Number.bgl. The Number is still giving you the N-S W-E coordinates for the tile but it is a bit less obvious how now. They now name tiles in increasing number order. If the state is all and all 25 bgl tiles wide they now divide the Number series in to stripes of 25. So Number 1-25 gives you the W-E coordinates for the most northern grid line of tiles. 26-50 gives you the 2nd most northern grid line of tiles. 51-75 gives you the 3rd most northern grid line of tiles and so on. If the state isn't a perfect N-S W-E square some numbers will be missing as their respective coordinates in the square grid do not cover any part of the state. So the fact that all numbers from 1-whateverthehighestnumberis are not present doesn't mean that tiles are missing. It's very easy to think tiles are missing if you don't know how they describe coordinates in a grid system. For example, If in V2 the first bgl was named xxx_A_04.bgl it didn't automatically make you miss the xxx_A_01.bgl , xxx_A_02.bgl and xxx_A_03.bgl. Or if in V3 the bgls go from say xxx_75.bgl to xxx_78.bgl you instantly wonder where did 76 and 77 go? Whilst in V2 the equivalent naming of the tiles would could have been from xxx_B_25.bgl to xxx_C_03.bgl and that doesn't instantly make you wonder why xxx_C_01.bgl and xxx_C_02.bgl aren't there?

With Skylake I'd say it's worth upgrading from 2500K. I run two systems myself. One OC'd SandyBridge-E and one OC'd Skylake. The Skylake system is giving me noticeable better FPS in FSX during gameplay without needing to look at any FPS numbers. When it comes to photo scenery texture loading however... the 6core SandyBridge-E is still noticeably better at that but at a lower FPS. OC'd Skylake with fast DDR4 is notably faster than SandyBridge, not to mention the improvements the whole platform gives. Yes. Skylake is 4.5 years later and 'only' faster enough to make a difference. But, you will clearly notice the difference without having to resort to reading numbers from a benchmark. If we look back a further 4.5 years we're at the introduction of Core2 and for that matter, the top of the line hardware at the introduction of FSX. The improvement from the first Core2 CPUs to SandyBridge was a lot, lot larger than SandyBridge to Skylake. A further 4.5 years back and we are talking the first Pentium4 CPUs and AMD Athlon, miles behind the Core2 line. So the single core processor improvements have really slowed down. But they haven't completely stopped.

I know its a bit of a late reply Bruce but its better on the SSD full stop. It doesn't matter if that SSD also contains OS and/or FSX. To use separate drives are only of relevance with old school mechanical hard drives. Photo scenery on SSD not only have the quickest initial load times, it also loads quickest whilst flying. I've tested this a lot.

SlowFlyer, the MSE UltraRes cities offers quite a good 3-D feel when you fly around at fairly low altitudes. It's all about scenery resolution vs altitude. Obviously it gets too blurry down at 200' but its not bad down to about 500' AGL. Here's west of Boston (Arlington?) just under 1000' MSL or about 650' AGL. First MSE Massachusetts x4: MSE Boston Ultra Res MSE Massachusetts 2.0 Default FSX textures Here you can really see the much better resolution in MSE UltraRes Vs MSE x4. All due to that 'optimized' compression. The same source data clearly gives way less resolution in MSE x4 even though they are both advertised as 50cm... Never the less, MSE x4 is still a lot better than MSE 2.0. You can also see the results of the different way they do water blending, but the MSE team have announced that they are gonna change how they do it in x4 and are holding further releases until they've sorted that out and they will update Florida x4 and Massachusetts x4 with the new way as well. Gonna be interesting to see how that looks. The MSE 2.0 stuff is too low res for a good feeling at 650' AGL, but higher up it doesn't look too bad actually. I've had hours/days of fun with it. The default FSX textures are not too bad resolution wise, unfortunately their not very accurate to the real world. I'd love to get the MSE x4 scenery with the same actual resolution as the Ultra Res scenery. The source data clearly is there and yeah, it will be taking up much more space, but I rather have the resolution please. As it has been said, the size of the scenery seems to be very much in line with the resolution. More compression leads to worse resolution. MSE Massachusetts 2.0 takes up 5.8GB on disk while MSE Massachusetts x4 'only' takes 8.8GB. There's the reason for not getting the 4x resolution. Boston UltraRes in the meanwhile takes up 14.6GB but it doesn't cover the whole of MA, but covers parts of NH, CT and RI as well. The .bgls in MA, NH, CT and RI fully covered by Boston UltraRes take up 4.21GB.. The UltraRes scenery clearly takes up more space than the x4. Did you want any more shots of the Lowell area fscottee?

Yeah, that Bing scenery of yours is way better resolution, regardless of colors. So it is using the same LOD level as the MSE x4. Interesting. The MSE UltraRes is actually slightly crisper compared to MSE x4 if you disregard the extra bleed through of default scenery here. If you look closer in the white lines in the red (is it a park?) in the top middle its clear that UltraRes is slightly better detail. It's clearly based on the same source so it must be that "optimised" 2x compression that is showing its ugly face. I'm no developer and don't know much about scenery scale but is the actual scale we see not depending on the latitude we are at? The textures are saved at a certain LOD level and the LOD level UltraRes and x4 scenery have gives a scale between about 70cm per pixel down in Key West and about 50cm per pixel up in northern Minnesota?

Think I managed to hover the Harrier to the correct spot. No slewing here :smile: This is what Massachusetts 4x looks like: And if anyone is interested, this is what MSE Ultra-Res Boston looks like: As you can see, it uses the same source data, but the water masking is different. Well, MSEs water masking until now has basically been to take the default vector data for the water and make the textures gradually transparent around that. That way they could through minimal work have the photo scenery textures blend in with the default water textures fairly nicely, however we also got horrible bleed through of the default ground textures around the water, but the join was fairly gradual. The x4 uses different vector data from default to make the textures see through for water, and they go from fully transparent to not transparent at all in a few feet instead of a few hundred feet. Here is what the MSE2.0 Massachusetts look like: We can clearly see that it uses different source data. And because that source data is a lot more washed out in color here, the default bleed through is absolutely horrible. Finally here is the Default FSX scenery with autogen: If you save the images and blink between them its very clear where the default scenery is bleeding through.

Yeah, the 32bit virtual address space used thay gives you the 4GB hard limit. We totally agree. If you were building a new machine and need to buy new RAM it's obviously not a bad idea to go for the 16GB instead if the 8GB. But as the OP has 8GB already it's not gonna make a difference for FSX to upp that to 16GB. Getting 2400MHz CL10 RAM would yield another 7% FPS. But overclocking the CPU will yield about 15-25% more performance alone. Without paying for the new RAM. Sure enough, both overclocking AND using faster RAM would be even better. But personally I'd be inclined to save that money towards a Skylake system with DDR4 instead as the RAM will have to be changed at next update. A 3570K with a z77 MoBo and water cooling is just waiting to be overclocked. Read up on it and try it. I'd guarantee you'd notice the difference in performance, and it is for free, ready to be done now.

Interesting that AM=12 didnt kill performance. When using AM=12, what load are you getting on core#2 and core#3 (the cores assigned)?

Not all CPU load is 'good' CPU load and the lack of CPU load isn't necessary a bad thing when it comes to hyperthreaded CPUs. Steve has made a lot of good points. One misconception is that when you have hyperthreading on, because task manager shows the CPU load in % as lower, less work is done by the CPU. If hyperthreading on a quad core is off and we have 4 threads runnig at full speed, one on every core, it would show as 100% load in task manager. If we turn on hyperthreading and still have the same 4 threads running, one on each physical core, the exact same work is performed by the CPU, even though task manager now shows only 50% load. If we now were able to double the number of threads to 9, working on the same job as before, task manager would show 100%, but we wouldn't get twice as much work done. Probably only around 20% more work would probanly be done in the same timeframe actually. I wonder if anyone has used Process explorer to actually see what threads are created by P3D? And more to the point, what kind of load are they creating on the system? FSX has the main thread (the first core assigned by the affinity mask) that should load up a core fully. At the times when it doesn't run at a full core load its not the CPU being the bottleneck any more. This thread should have its own PHYSICAL processor core alone just as Steve has been saying. If it has to share that physical processor core with anything else the performance of the sim is suffering. The other cores that are assigned by the affinitymask are responsible for loading ground textures, the terrain model and autogen. They are already designed to run separately from the main thread. If two are sharing one physical core with hyperthreading, together they will perform more work in a set time frame then one single thread alone on the same physical core would be able to do in the same time frame. On top of this, FSX has 3 other threads that produce any significant CPU load. One de-bug thread, one sound thread and one thread that is loading most data from the hard drive. This can all be seen in process explorer. These 3 threads are not controlled by the affinitymask setting and are run on either core the OS seem fit. The de-bug and data loading thread are assigned a prefered affinity at game startup, whilst the sound affinity changes every time you select any other window in windows. We don't want these threads to end up on the same physical core as the main thread. The data loading thread can be very bursty in its load. In certain scenery it will load up a full core frequently, in other scenery it will stay at a low core load all the time. Do you run any addons that also create a lot of CPU load at times? If there's no vacant core for the OS to schedule it on, it has a high chance if getting put on the same physical core as the main thread. That's why different affinitymasks work better with different systems. Does P3D alone have any more threads created that cause a significant CPU load? LM have re-written a lot of code I believe. Are these potential threads assigned with the affinity mask? The best thing is to know your own setup. Process explorer will give you many answers. Personally I know when I fly around my MSE photo scenery in my Harrier I can happily use affinitymask 4089 on my hyperthreaded 6core CPU. If I head over to the UK and the Horizon photo scenery with added airports and autogen, the load on the data loading thread becomes way too high for that affinitymask and 4084 works better. If I had other add-on that frequently caused a high CPU load I'd consider a different affinitymask that left more cores unassigned.

When something looks too good to be true it normally is. That still applies. Unfortunately there's no massive load time improvement with Skylake. Even though I double checked, I basically messed up. There were several MSE2.0 states missing in the scenery.cfg I found out when I checked it over once more. Therefore, I've had to re-run the texture load and load time test. I've kept the original data in the result image in red and marked it as incorrectly configured as the image will still appear in the original post above, and its too late to edit the text in the post. So here are the updated results: Unfortunately there's nothing exciting in them. The incorrect scenery configuration had only a minor effect on the texture loading but had a larger effect on load times. Basically, the texture loading is still in line with the FSXmarkCPU improvements while using the same RAM settings for Skylake and SandyBridgeE. And now the load times are in line with them as well. Sad but true. There's still a healthy improvement compared to the several generations older SandyBridgeE clock for clock, like for like. But compared to Haswell, the indications are that there won't be much Improvement with Skylake when it comes to texture loading or load times.