Jump to content
The simFlight Network Forums

airforce2

Members
  • Posts

    204
  • Joined

  • Last visited

Posts posted by airforce2

  1. Geez...not another one...what is this, the "Trollz-R-Us" forum?

    Hey WarpD, is it fair that Microsoft profits by selling Flight Sim to every one who wants to use one of your panels? Is it fair that Microsoft gets to profit from selling the operating system that flight sim requires to run? Sure it's fair...if you don't want to pay them to reap the benefits of their work, then go find something else more to your liking and price range.

    Pete's more than fair...he accredits...FOR FREE...legitimate freeware works that use his interface software. He sure doesn't have to, and with all the crap he takes from people that can't bother to read his policy before spewing forth with accusations and complaints, he'd be more than justified to just ask everyone that uses FSUIPC to pay for it. It's certainly his right...none of us have any claim to the fruits of his labor for free.

    What's particularly annoying to me and I presume many others, is that you can't afford Pete the decency to have this discussion with him via private e-mail, rather than tossing this sort of accusatory rubbish out into a public forum. It might have saved you some much-deserved embarassment.

  2. Pete;

    I don't doubt that guys land 'em crabbed. It may be that the pax get uncomfortable coming down final in a bank...it does feel a wee bit unnatural, especially if you don't know what's going on. In my years of GucciJet aviatin' (in Gulfstreams) I generally employ the technique of flying final approach in a crab until about 1-2 mile from the threshold, then establish a wing-low slip in plenty of time to be stable for the landing.

    Then there's the whole discussion of the "reverse weathervaning" or "buggywhip"...when you touch down in a crab the pointy-end will swing rapidly to point along the ground track.

    I used to be an instructor in the T-38 Talon, which is one jet you do land in a crab intentionally (but it's light). That buggywhip effect would spin yer eyeballs pretty good when you planted one in a stiff x-breeze.

    Cheers

  3. Pete;

    The icing level reported by WeatherSet2 during another zero-airspeed incident was 4...I think the problem may be that even pitot heat is not effective in extreme icing (as would be the case in reality). But...to see that level of unforecast icing routinely isn't realistic...perhaps the probability programmed into the randomizer is set too high.

    Also, significant structural icing at temps below ~-20 deg C is very rare, as ice tends to sublimate off the wings. Hence icing at 35000 or 52000 ft (as I've observed a few times in the last couple hours) isn't very realistic...not sure if that's the AWI or ActiveSky doing that.

    Anyway, I'm turning random icing in clouds off in FSUIPC...if I see another zero-airspeed hit with it off I'll readdress here.

    Cheers

  4. Pete;

    Not completely true...real aircraft do indeed weathervane in the air. The airplane rotates about the CG...and the side load imposed by a crosswind striking the vertical tail at considerable arm (distance) from the CG will produce a very real leeward yawing moment...aka weathervane. This is most noticeable on takeoff with a strong x-wind...as soon as you break ground (where you've been steering straight down the rwy with the aid of nosewheel steering) the airplane will yaw to put the pointy-end right into the relative wind. The cause is the fact that the airplane was not flying directly into the relative wind while on the ground, and at liftoff, it still has a considerable inertial vector in the direction of its ground track at liftoff (straight down the runway), leaving the aircraft in flight at an angle offset laterally to the relative wind. If one adds rudder to counteract the yaw, the ground track will shift downwind and progressively less rudder will be needed until, after a few seconds, the airplane is at equilibrium into the r.w.

    I'd be surprised if crabbed landings in any transport category aircraft are enything but poor pilot technique. As I understand certification standards (FAA and/or CAA), the aircraft should be capable of holding a wing-low slip with the fuselage pointed straight down the rwy...with an adequate bank angle safety margin...at the max certified x-wind. The side loads imposed on the side braces and support trunions in a crabbed landing are pretty severe.

    Regards

  5. Pete;

    I wish it were that simple...probe/pitot heat's on and verified (in both the panel and using FSLook to make sure the sim thinks so) in all three occurrences. PM also reports Pitot Heat on at the time it happens.

    The A/S drops abruptly to 0...then without any other action on my part, it returns 20-30 sec later. In the meantime, the Project Magenta MCP has poured the coals to it, sensing that we're seriously slow (can't get much slower!), so when A/S indication returns, I'm at Vmo+20 or so.

    Cheers

  6. Pete;

    Using ActiveSky wxRE 1.91 beta 6, I am seeing a recurring problem where the indicated airspeed reported by FSUIPC via WideFS drops to zero for 20-30 sec as I approach a cloud layer in the descent. The latest episode occurred descending through ~14000 ft MSL close to the top of a scattered cloud layer with bases at perhaps 12000 ft. It appears that only airspeed is affected...other params appear normal.

    This behavior began with installation of both FSUIPC 3.06 and the Beta 6 of wxRE. I also reported this on the ActiveSky forum, as has at least one other person.

    Regards

  7. Pete;

    Tried it without APS.DLL in the modules folder...no change.

    Have been doing research this morning on interrupt affinity masking...there's a utility in the Win XP Server 2003 Resource Toolkit that allows you to set processor affinity for drivers doing hardware interrupt handling, which may be at the root of this problem with serial I/O.

    The utility is called intfiltr.exe...you can download the WIndows XP Server 2003 resource toolkit from support.microsoft.com. The utility applies to Win XP pro as well as Win XP Server 2003 per the docs.

    With the serial I/O interrupt handling set to CPU0, the PFC driver still drives both CPUs up to 100% when FS9 is set to dual-processor affinity. I've also discovered that the sound card (Audigy) does not take well to having its interrupts tweaked...it hisses and pops like mad when you do. Lots of other interesting possibilities are unfolding.

    Cheers

  8. Pete;

    I just tried with the PFC controls connected via a Belkin F5U103 serial-to USB adapter. No change in behavior from previous post.

    One thought...would it be possible to compile the DLL as a standalone exe rather than an FS module? It might be handy to be able to hang the PFC onto one of the clients and feed the flight control inputs to the server via the WideFS data stream.

    Cheerio

  9. Pete;

    I did some experimenting today...found a couple more really strange things about HT and processor affinity I can't fully explain.

    I restored a virgin copy of FS9.exe without the affinity mask. Then I assigned an affinity to each DLL in the modules folder separately using IMAGECFG, putting G2D, G3D, and Terrain onto vCPU1, and the others to vCPU0.

    With pfc.dll removed from the folder, FS9 starts running with both vCPUs at 100% and ~12fps. I then manually set affinity for FS9 in the task manager to CPU1, and it runs 100% on vCPU1 with minor activity on vCPU0, and frame rates go up to 20fps on average. Then...and this was a surprise...if I reset FS9 to run on both vCPUs, the load will then run shared equally across the vCPUs at around 50% with a lot of flux +/- around 15-20% on both sides...and frames remain at ~20fps.

    Then I repeat the experiment with pfc.dll running. Every time I go to both vCPUs with pfc.dll up & running, both virtual processors shoot up to 100% and frames drop back to around 12. Clearly something in pfc.dll is not living happily with whatever does the HT load sharing.

    I'm heading out to find a USB-serial converter shortly...I've been wanting one for a while anyway. Will advise how that goes later.

    Cheers

  10. I'm not sure why on some systems FS2004 seems to already have an affinity to run on a single vCPU. On mine, with FS2004 running I saw both vCPUs running at 100% before setting processor affinity.

    I feel certain that this is why some folks see a marked improvement, and others nothing.

    Just out of curiosity, was your system built with the HT CPU from the beginning, or was the CPU upgraded after the OS was first installed?

    Cheers

  11. An even better way of constraining FS9 to run on a single virtual CPU on an HT CPU is using the Microsoft IMAGECFG utility (an older NT/2000 utility that works fine in XP -- do a google search). Command syntax (from an MS-DOS Command window):

    IMAGECFG -a 0x1 \fs9.exe

    This writes a processor affinity mask into the executable. 0x1 specifies virtual CPU 0, 0x2 specifies vCPU 1, and 0x3 uses both 0 & 1 (default). FS will always run on the specified virtual CPU(s) from that point on.

    I have done the same to the other utilities I run on the machine while FS is running, only restricting them to the opposite vCPU.

  12. Pete;

    In my case I have an Intel Pro/100 VE integrated LAN adapter on the Gigbyte 8IG1000 Pro (i865G) motherboard.

    In Win 2000 or Win XP:

    Go to control panel -> system -> hardware tab -> Device Manager

    Find the entry for Network Adapters, right click on the LAN adapter and select Properties then Advanced tab

    In the Pro/100 VE there are way more than the usual 3-5 settings available. It includes Adaptive Technology, Adaptive Transmit Threshold, Coalesce Buffers, PCI Bus Effeciency, and Transmit Control Block parameters, all of which effect data store-and-forward and coalescing. In the case of this adapter, setting Adaptive Technology to 0 turns out to be the magic bullet that turns it all off.

    The symptomology that will be present is a choppy flow of data...in one or possibly both directions...and significant lag and jitter in the data stream.

    Hope this helps

    Cheers

  13. Pete;

    My analysis of the problem was spot-on, but it turns out the packet coalescing was happening in hardware! The Intel LAN adapter integrated into the new client PC's motherboard (Gigabyte 8IG1000 Pro) has it microcoded into its firmware. The supplied driver configuration utility, if you dig deep enough, presents options to turn it off.

    I suspect this'll come up again if this feature starts showing up on more motherboards.

    Cheers

    Bob

  14. Pete;

    Have been trying for several days to get back up with FSUIPC 3.04 and WideFS 6.02, right now under FS2002 with 4 Project Magenta clients all running on a single very fast PC. As per a previous post, I had to rebuild my system over the weekend.

    I'm getting massive lag (up to 10 sec) in commands from the PM MCP. Watching the WideFS frame counter on the windows menu bar, I see very steady and smooth data flow from the server to the client (also reflected in very smooth displays) but the data from the client to the server is coming in irregular bursts. It appears to be related to packet coalescing in TCP/IP again. The packets coming out of the server are fairly large (lots of data changing) and keep it flowing...the packets built in the client are probably much smaller, and look to be getting consolidated.

    Does WideFS use the TCP NO_DELAY socket setting? Any other ideas how to force the packet writes? It appears that reducing the value of tcpWindowSize in the XP registry could have that effect, but it would adversely impact regular internet comms on that PC. Another possible rub is the installation of tcpip v6 in a recent windows update...no idea if that is somehow having an effect, but it's possible I guess.

    Thoughts?

    Thanks

  15. Pete;

    I don't dislike Intel CPUs, but I do think the HYPErthreading is a non-factor for FS. With the HT disabled in BIOS, it's still a very fast CPU. I took an existing machine with a 2.8GHz non-HT CPU and dropped in a 3.06 GHz HT one. Although the found hardware wizard detected and loaded some drivers for the new CPU, it performed poorly...I doubt all the necessary support drivers were loaded correctly that way.

    The PC, when configured with a fresh install of WinXP, beginning at the outset with the HT CPU installed, is very stable and performs at par with a ~9% faster CPU. It's the major butt pain of reinstalling everything and recreating the config that made it so painful. If you're starting from a clean HDD, I think you'll be OK. I don't mess with AMD stuff much...a number of friends have had issues with them--they tend to be finicky about which RAM modules work, as well as real heat-monsters. The prevalence of Via chipsets on AMD boards is also troubling--their drivers have left me wanting before.

    The mobo in question is a Gigabyte 8IHXP with an Intel 850E chipset plus 1 GB 1066MHz RDRAM. The 2.8 GHz CPU went into a new Gigabyte mobo with an i865G chipset...so far, so good with that one and 1 GB of dual-channel 333MHz SDRAM.

    Cheers

  16. I'm reaching the end of a very frustrating 3-day weekend here...

    Microsoft support was of no help...the quasi-literate dipweed that answered the support call Friday morning didn't send the hotfix to me all day Friday despite multiple e-mail contacts...in fact I've gotten it, but not from them. It made no discernable difference in performance in the first attempt, and subsequent experimentation with the HT CPU resulted in an OS meltdown that resulted in eventual complete re-installation of the OS and probably 75 applications on my primary PC. Thankfully I am fairly disciplined in backup habits, so I lost very little other than the 2 days to recover things back to a useable configuration.

    After reinstalling Win XP from scratch with the HT CPU in from the begining, I'm seeing ~25 fps in clear wx, 12 in stormy (the worst for wx here so far). That's with HYPErthreading disabled in the BIOS. Frame rates are nearly halved with HT turned on. I did some other experimenting with CPU-intensive applications other than FS, and HT failed equally miserably there. It seems to help in cases where multiple threads run with relatively low processor loading and paging activity. The performance drop is probably due to bottlenecks in the L2 cache or other hardware chokepoints that both virtual CPUs are hitting.

    Anyway, as far as I'm concerned, HYPErthreading is little more than a lot of HYPE, with nothing to recommend it to the flight simmer. And decorum prohibits me from posting my thoughts about Microsoft's customer...ummm...support (?).

    I need a beer.

    Cheers

  17. Pete;

    I just dropped in a 3.06 GHz hyperthreading CPU into my system...had the most unpleasant surprise of seeing a sizeable decrease in performance compared to the Intel 2.8 GHz (non HT) that preceded it.

    I found this article in my research.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;815227

    It says that there's a known bug in the UnMapViewOfFile function in the WinXP kernel that causes performance degradation in Windows XP machines with SP1 installed and multiple logical processors (hyperthreading or SMP). As I recall, FSUIPC uses file mapped views.

    I'm calling Microsoft tomorrow to discuss the fix...not sure why, rather than posting the fix, they post a KB article that says "call us." Grrrr

    Regards

  18. Hi Pete;

    I agree...keyboard control is not a suitable stopping point, but I do suggest it to PMDG as a first step due to its commonality across many different types of input devices. I would very much like to see them work with you to make their controls accessible from the PFC module.

    Also, for Lefteris, if you're reading this thread still, I'd suggest cc: copies of your e-mails to eric@flypfc.com Bart and Mike and the rest of the gang seem to check that one regularly since it's listed as the tech support e-mail address on their site.

    Regards

  19. This plateau effect is due to a MSFS limitation that makes all airports sit on a zero-slope flat plate. In the case of McCarran, there is a sizeable elevation difference due to a significant (~1%) E-W slope along an extremely long runway, yielding approximately 120 ft elevation difference from one end of airport to the other.

    The high-resolution add-on mesh sceneries (I have FSGenesis) are accurate...but MSFS puts the field on a flat plate at field elevation (highest point within the field boundaries), making for a sharp drop-off from the artificial perfectly-flat airfield plateau to the accurately rendered terrain just off the airfield.

    The only fix would be to have someone modify the terrain mesh to more gradually smooth the airfield-to-surrounding terrain transition area. That's no small feat.

    Regards

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.