Jump to content
The simFlight Network Forums

Do you like the A380?  

6 members have voted

You do not have permission to vote in this poll, or see the poll results. Please sign in or register to vote in this poll.

Recommended Posts

Posted

Hi Pete,

I’m using widefs 6.47. I’m running PM PFD on a client. For the first 3 minutes of a session it’s perfect. Then lagging starts. It grows from 2 secs to nearly 25 secs. I’m running the Eicas on an other server with the same settings and it has no problems at all. I have tried both TCPIP and IPXSPX. There isn’t any difference.

System specs.

Server. P4 3.0ghz, 1024mb DDRam, ATI Rad 9200 256mb Running Win xp pro sp2.

Client 1(PM PFD) P4 1.4ghz 512mb ram ATI Rad 9200 128mb running Win xp pro sp2.

Client 3 PM EICAS) P2 800mhz 372mb ram MX440 64mb running Win 2000 pro sp4

There are other clients running Win 2000 pro with various applications all working fine. It’s only the PFD system that’s lagging. I have followed Enricos and Katy’s Network setup and have avoided “Auto” settings. If its ok with your good self can I email the ini files and log files for the Server and two clients?

Kind regards.

James

Posted

I’m using widefs 6.47. I’m running PM PFD on a client. For the first 3 minutes of a session it’s perfect. Then lagging starts. It grows from 2 secs to nearly 25 secs. I’m running the Eicas on an other server with the same settings and it has no problems at all. I have tried both TCPIP and IPXSPX. There isn’t any difference.

I've heard of this sort of thing before. It's not common, and I don't know what causes it, but it has something to do with Windows and drivers on one or both machines.

WideFS itself cannot queue data. If it runs slower because of resources, that just means a slightly jerkier update rate -- because when it passes the data frames to Windows for transmission it fills them with the current values, not some values which were valid even a second ago, let alone 25 seconds!

So, the queuing is occurring someplace either in Windows on the sending PC, Windows on the receiving PC, or possibly a buffering switch, hub or router in between.

How you determine where things a going wrong and why I am afraid I do not know. I think one of the sufferers of this type of problem got around it by a complete re-install of Windows etc, but I also seem to recollect another found there was some interaction with some other networking software, presumably firewall or virus check or something.

I hope one of the earlier folks will see this and chip in here. The threads which contain the original chats will still be here, in this forum, somewhee, but searching for them may take some time with there being some many accumulated messages now.

If you are using Project Magenta you may try using the PM newsgroup, as there are almost bound to be folks there who've seen this too.

Regards,

Pete

Posted

Not a sufferer of this myself (haven't gotten the hardware to run my PM yet, but it's on the way...) so I can't be specific, but as a Network Admin I do know a thing or two about these sorts of things.

Obvious suggestions would be:-

  • [*:ff362]Firewalling/A-V software (and the like) - Have wide-open permissions between all your FS machines. Check especially on the XP SP2 machines, since the Windows Firewall was tightened up (and turned on by default) in SP2.
    [*:ff362]Networking hardware - If you can afford the extra hardware, put all your FS machines onto their own switched subnetwork. Get a little 5 or 8 port 10/100 switch (depending on how many machines you have) and plug only your FS machines into it, and cascade it to the rest of your network. Never use a hub for this, hubs *will* cause problems with packet collision!
    [*:ff362]Windows networking - A much overlooked issue. If you don't have a Windows Domain of some description on your network (I use a Samba server myself), and/or correctly and fully specified hosts and lmhosts files (look in %windir%\system32\drivers\etc) on all the machines, much of the Windows network communication will be by TCP/IP|IPX/SPX broadcast! This is extremely wasteful of CPU cycles (all your machines have to process these broadcast packets, so that one machine can answer it)
    [*:ff362]Cable runs - keep all your ethernet cables as short as you can, but never less than 1 metre. Avoid coiling network cables, and try to keep the ether cables away from power cables whenever possible.

One final suggestion, maybe think about getting a copy of [ XPLite ] and uninstalling as much of the unnecessary Windows XP clag as you can (leave IE installed!). It has made a vast improvement to my XP SP2 FS client machine.

Posted

Hi Pete,

Cheers for that. I suspect you are correct as ever. I went thru the news group and found a few tips. After alot of tweakink and testing I traced it back to some sort of conflict between the PC thats running the CDU and the PFD. I found that by letting FS have control of the netdir, things worked a lot better. Also pulled the fs frame rate from 25 locked to 20 locked. This improved things by 12/13 seconds below FL100. :D

@ Murray,

Wow, thats a lot of info! Im using a belkin 5 way hub. My big problem is my PC rack is behind the Left seat with 3 machines in there and 2 more where the Radar dome would be. This cables are at least 2 meters. :cry:

I will have a look at XP lite as you suggested.

No doubt I will be looking to your skills for further help.

Many thanks agin guys.

James

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.