Jump to content
The simFlight Network Forums

airforce2

Members
  • Content Count

    191
  • Joined

  • Last visited

Everything posted by airforce2

  1. 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
  2. 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
  3. I ended up doing a clean install of Win XP after my upgrade disaster. FS2004 frame rates with HT enabled are approximately half the rate with HT enabled, using PMDG panel or one of the stock Cessnas. I saw 8-9 fps with HT on, and 17-18 with it off, all other tings remaining the same. Cheers
  4. 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
  5. Nope, the repair install was the first thing I tried. After that I got a BSD telling me I had an INTERNAL_VOLTAGE_ERROR problem on the mobo...never was able to resuscitate XP after that. Cheers
  6. 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
  7. 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
  8. 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
  9. Pete just released version 3.01 to deal with a few registration problems...make sure you've got that one. Regards
  10. 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
  11. I might add that a keyboard control interface would likely serve the broadest span of users as an initial effort, given that PFC and many other devices can be programmed to generate keystrokes that could be mapped to panel keyboard controls. No hardware beyond a PC keyboard should be required for that. 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.