244=(11,11,01,00) the two paired up cores (11,11) with the secondary FSX threads, mean they are always fully utilised. Although core 0 (00) is free for other threads starting up, core 1 (01) with the main FS thread, has a higher probability of being hit by other threads starting than the two pared up secondary FS threads. Which sounds like what you may be describing with ASN coming in with the weather updates. The two paired threads also use double the resources over one pair on two cores, and double the synchronizing with the main thread, and may be underutilised.

 

Thank you Steve!

The AM is the only bastion that hampers full time fluidity in FSX for me.

 

Your thoughts (see above) about AM244 exactly represent my experience and I am looking for an answer to this frequently and for a long time...

So instead of AM244 I will give AM170, 168, 42 and 21 a try.

 

The latter 21 (10101) remembered me somehow of a NASA Apollo mission bit code. So I started a Google search and came across an interesting story about a wrongly set bit which caused the Lunar Excursion Module computer (by M.I.T.) to slow down during approach. This bit (set to "on" because of a failure in the procedure check list) turned the ascent radar to "AUTO mode" and by that made the computer wait for unnecessary ascent radar data. The performance hit was about 20%...

Hopefully finding the right AM bit combination will also give some performance boost in return  B)

https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html

 

I just downloaded P3D v2.5. Let's see if it goes off like a rocket...

 

Here is a quote from referenced article:

 

The on-board Apollo Guidance Computer (AGC) was about 1 cubic foot with 2K of 16-bit RAM and 36K of hard-wired core-rope memory with copper wires threaded or not threaded through tiny magnetic cores. The 16-bit words were generally 14 bits of data (or two op-codes), 1 sign bit, and 1 parity bit. The cycle time was 11.7 micro-seconds. Programming was done in assembly language and in an interpretive language, in reverse Polish. Scaling was fixed point fractional. An assembly language ADD took about 23.4 micro-seconds. The operating system featured a multi-programmed, priority/event driven asynchronous executive packed into 2K of memory. The Mean Time to Failure (MTBF) of the machine in a space environment was calculated at 50,000 hours -- almost 6 years, and it never failed in flight operations. It was truly a marvel for its time, a tribute to M.I.T.'s designers, and it accomplished a most complex mission.

 

Keep things in perspective, Intel was only one year old and was working on an integrated chip (much to the chagrin of TI) for a Japanese watch maker. That chip became the 8008 a few years later.

 

 

The Mean Time to Failure (MTBF) of the machine in a space environment was calculated at 50,000 hours -- almost 6 years, and it never failed in flight operations.

That was well before "some other folks" :ph34r:  started computing!  

It is really a fascinating excerpt of one of many NASA articles...

 

And to find and read all that great stuff today is made possible by the ongoing improvement of technology. One can actually go back to the invention of the reel and beyond. And in the other direction of the timeline e.g. "Startrek" gets reality and it still goes on...

B)