Commercial Member
  • Content count

  • Joined

  • Last visited

Community Reputation

110 Excellent

1 Follower

About Luke

  • Rank

Flight Sim Profile

  • Commercial Member
  • Online Flight Organization Membership
    I belong to both VATSIM & IVAO
  • Virtual Airlines

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    Sweat Mountain, GA

Recent Profile Visitors

2,367 profile views
  1. Luke

    AVSIM Server Funraising Drive

    Silly question, but have you considered just moving the forums to AWS? Cheers! Luke
  2. Luke

    Froogle's take on FSW and possible impact on P3D

    This appears to be spot-on correct. DTG has no relationship with L-M and cannot sue to enforce Microsoft's IP rights - only Microsoft can do so. The fact that they have not would strongly suggest that they find the current status quo and potential misuse of the academic license terms acceptable. My completely uninformed speculation says that they may get a flat cut of each seat sale (in which case they don't care who sells a copy, LM or DTG) or they have an agreement with LM that there is a price floor for the academic version to avoid undercutting the DTG version. If one still cannot make a viable product when competing against something twice or three times the price, not Microsoft's problem. Cheers!
  3. Luke

    Unknown Simulator Version

    Unfortunately, P3Dv4 isn't a supported configuration yet - I need to do the backport soon. End of month. Cheers!
  4. Luke

    Door Offset Support Request

    Each door is a different byte in the array. You can either read the whole array, or add the offset to 0x65DC and read a single byte from there. Cheers!
  5. Was just going to post a link but great minds think alike. I love mine; it's quiet, stylish and keeps the dust out. Cheers!
  6. Luke

    My PC reboots by itself

    Yes, it's likely the age or quality of the PSU, not the wattage. A modern CPU and video card may pull 200W under load at most. Usually when people think they have solved their problems by getting a new, larger power supply they attribute it to the increased capacity rather than replacing a defective item. Cheers!
  7. Luke

    P3D no longer starts.

    I expect you'll need to download and run the installer I linked to. I found this on the TFDi site for their 717 - I believe it has the same dependency and same issues. Cheers!
  8. Luke

    P3D no longer starts.

    RAASPRO will not work properly if you have a 32-bit office install. You'll need the 64-bit Access 2010 driver and then RAAS will be happy again: Cheers!
  9. Luke

    Simmarket False Identify Purchase Please Help!

    They're not completely wrong. Generally speaking if you want to attack an e-commerce site you try and get their data from them directly, not by intercepting it in transit. It's similar to robbing a bank; you are better stealing everyone's money after hours than robbing people one by one on their way in and out of the bank. However, HTTPS certificates are now free and having encryption is rapidly becoming the price of entry for a web site, never mind one handling financial transactions. If they can't do something as basic as HTTPS, what other important security precautions are they skipping? Cheers!
  10. Luke

    Simmarket False Identify Purchase Please Help!

    I'm surprise they don't force a redirect to HTTPS. It's literally a two-line Apache config change. Cheers!
  11. Luke

    Constant writes to system drive

    You will discard your SSD long before it reaches its lifetime limit of writes. I do about 3-4TB a year to my system drive. Given a lifetime of around 1000 TB of writes, I don't expect it to die anytime soon. Cheers!
  12. Luke

    Huge problem v4.2 and 737

    To be precise, the issue is with 5.123c only. 5.123b works just fine with P3D v4.2. Cheers!
  13. I think the statement of yours I have most difficulty with and am addressing is "I'm just not 100% confident that given a lack of thread awareness in FSX that the HW and OS will always get things done in the correct way". The hardware makes no difference, and to be honest the OS should make no difference either unless the scheduler has changed. Looking back on your statement, in retrospect you're agreeing with me more than I initially gave you credit for - you're saying that FSX isn't managing the threads. I just am unsure why you think it's a bad thing or that the operating system will do so poorly. It will be correct. Agreed. The core of FSX (and FS9 and other before it) was guaranteed to run on a single thread, so they didn't make it thread-safe. Why would one? That's probably why performance hasn't scaled well and part of the challenge. Keep in mind that IIRC Phil Taylor was not a developer, he was the Program Manager for FSX. That's a significant role in the Microsoft model, making decisions and tradeoffs on the product which by necessity requires some technical understanding, but it's very different than being a core developer. I would be very surprised if he wrote even a single line in the actual code base. That doesn't mean his statements are invalid; it just means that there's plenty of other reasons why you may see more core utilization. 1) They estimated incorrectly. TBH if I am in the same order of magnitude before further optimization with my estimates I consider it a win. 2) They (gasp) under-promised and over-delivered. 3) They made assumptions based on the cores of the time, which were often P4s with HyperThreading or dual-core machines. Perhaps they were able to scale better than they expected. 4) They made assumptions based on the data of the time. Perhaps our scenery, landclasses and terrain mesh are denser than 2006 and their work scales better with demand. 5) I'm not sure about the API calls or driver work - wouldn't that be reflected under kernel, not user, time? I don't see substantial kernel usage on the other threads. The API calls won't be multi-threaded under the covers unless they say so, and that's almost certainly not going to change behind the scenes. Microsoft (for good reason) is exceptionally averse to changing the behaviors of core windows APIs. 6) What are your add-ons? I'd venture that things like FSUIPC, AS and other add-ons that wholly or partially execute within FSX are adding to this number. I'm just saying that I wouldn't take a statement from Phil of "on the order of 20%" and draw too much extrapolation if you're getting 40 or even 60% more CPU usage. Cheers! Luke
  14. Not bad - we topped out around 480m transactions per day but we're definitely in the same ballpark and faced some of the same issues. (And yours was I expect more write-heavy than mine.) The biggest difference that you may have faced that I didn't (through deliberate design) or that MS faces is the notion of cross-platform compatibility. In the FS world, we're all running on x86(-64) on Intel. (thankfully) I am in violent agreement with you on this statement. But it it's important to note that this statement explicitly doesn't cover the notion of scheduling your own threads and processes. I agree with you that your threads should be limited in scope, efficient in their execution, ensure that locks or other exclusive access sections are as short as possible to avoid blocking other threads. I agree, because we don't know what other threads are running or where they are - threads are simple and dumb because our apps are simple and dumb and let the kernel handle the scheduling. I agree with you that the article is old, and that's the point. Even over a decade ago, there were questions regarding whether Fibers were appropriate. They were a "solution" to the problem that context switches between real threads were too expensive, and even then people were suspecting that it would be a minor or non-existent problem on faster chips. As you point out, modern standards don't use fibers at all - they use 'real' threads, which are up to the OS kernel to schedule and run. Honest question - what does Intel have to do with it? The CPU is just running a set of instructions on a given core, no more, no less. The chips may do a little bit of speculative execution, but beyond that they don't do what you don't tell them to do. Here's the fundamental business problem I have - let's assume that you're right, and FSX had a vastly better code execution engine than the Windows kernel. If that was the cause, why on Earth would Microsoft not immediately steal that person and have him (or her!) rewrite the NT kernel? Why would that developer want to work for a significantly lower salary? Companies aren't dumb. Talent ends up in the right place (even if at a competitor). Again, I've never actually met anyone who can write a world-class thread scheduler or VM manager. I've seen or heard of a lot of people who thought they could, and that's where they got into trouble. Cheers! Luke PS: On a side note, I wonder when P3D drops its own memory management for textures and models and merely memory maps everything into VAS and lets the OS handle it.
  15. Probably, but I've never seen the code. I suspect the low hanging fruit got captured in FSX SP1 and LM has been nibbling away at it since then (IIRC gauges are run on a separate thread in v4). The best analogy is to think of a big Thanksgiving dinner for your family and relatives. It's a lot of food and different courses, and for you to do it by yourself in your kitchen will take a long time. You enlist your wife to help you, and things go a lot faster. But as you start adding more and more people to help you, there are certain things you simply cannot speed up. For example, the turkey takes a set amount of time in the oven. You can't go from 4 hours to 2 hours by getting a second oven. If it's at a different temperature than what the pie needs, you're stuck being unable to bake the pie until the bird is done. When there's several of you in the kitchen, you start getting in each other's way, or the ingredients you need may not be ready yet by another person. That's the challenge with multi-threaded code - it's a process problem more than anything else: dividing up the work in a logical fashion where things can be done independently and conflicts or stalls minimized. That's rarely easy. In a previous job I built a system for automated processing of weather imagery - it was pretty easy because we got a set of images that we split into tiles, resized, shrunk the color palette and then converted to PNG. It was an embarrassingly easy problem because there were almost no data dependencies so the work could be done independently without waiting on anything else. Just like our Thanksgiving example - you and I can each cook Thanksgiving dinner and gain double the productivity because we're each using our own family and kitchen to make it. I don't think P3D is that way - it probably could get better but it likely involves some significant rewrite. Cheers!