Lag time between Client GAIFR and Server MSFS

[hal28]

Please help...

I have latest registered versions of FSUIPC and WIDEFS on XP pro.

I am using FS2002 and GAIFR from ProjectMagenta.

I am having trouble with the delay between control input on the MSFS server and it actually happening on the Client GAIFR machine.

I am using a simple LinkSys 5 port Hub 10/100 EFAH50W, an on board NVIDIA nForce MCP Networking Adapter on the server and a RealTek RTL8139 Family PCI Fast Ethernet NIC on the Client.

I am using TCPIP and have set the UseTCPIP=Yes in the WideClient.Ini file under the [Config] section, and I have been told by Katy Pluta that I should have the same setting in the WideServer.Ini file under the [Config] section.

When I put that entry in, and run MSFS, it is automatically removed somehow. When I go back in to WideServer.Ini it is not there.

I have also set the TimeOut setting to 0 in the WideClient.Ini which has made some improvement.

If anyone can lend a hand I would be VERY appreciative, as I can't think what else to try.

Many thanks in advance.

[Pete Dowson]

I have latest registered versions of FSUIPC and WIDEFS on XP pro.

The "latest" being the ones listed above as Supported? Version numbers are always more exact. Some folks say "latest" but actually mean the last ones they saw or downloaded, maybe months before.

I am using FS2002 and GAIFR from ProjectMagenta.

I am having trouble with the delay between control input on the MSFS server and it actually happening on the Client GAIFR machine.

I have read a couple of similar stories on the PM support site. They mostly sound like some sort of graphics processing hiccough from what I've read.

I am using TCPIP and have set the UseTCPIP=Yes in the WideClient.Ini file under the [Config] section, and I have been told by Katy Pluta that I should have the same setting in the WideServer.Ini file under the [Config] section.

When I put that entry in, and run MSFS, it is automatically removed somehow. When I go back in to WideServer.Ini it is not there.

Ah, so you do really have "the latest". Yes, as per documentation, it is not used on the Server any more, as it automatically supports both IPX/SPX and TCP/IP clients. Seems that Katy is a little out of date -- I think this may be due to the fact that she has been moving house and probably hasn't had time to keep up to date.

Please, whenever you update any of my programs, peruse the History section. For WideFS, this is right at the end of the WideFS.doc after the heading

History of Recent Changes

You will find, in the section "Version 6.41 includes ...", this paragraph:

Finally, quite a big change: WideServer now automatically provides a service for both TCP/IP and IPX/SPX protocols if they are both installed. The “UseTCPIP” parameter is no longer used in the WideServer INI file (it will be deleted).

These changes are also listed in the "RECENT RELEASE CHANGES" announcement near the top of this Forum, which you could read instead if you wish.

I have also set the TimeOut setting to 0 in the WideClient.Ini which has made some improvement.

I think that Timeout=0 has always been recommended for PM use. It is actually a better value for most aspplications now that most folks are using Windows 2000 or XP, which multitask better than Win98/Me. In the next version of WideFS (due next week), also pre-released as 6.414 on the PM support forum, the Timeout parameter is actually deleted and instead an "ApplicationDelay" is added, which does default to 0.

If anyone can lend a hand I would be VERY appreciative, as I can't think what else to try.

If there are no errors showing in the WideServer and WideClient LOG files, then there is nothing wrong in the WideFS operation. It sounds like either something slow in the Client -- though I would expect something like video processing delays to cause jerks rather than consistent slow downs -- or some sort of extensive buffering going on between Server and Client, in which case the switch might be suspect. Does it operate any buffering? Seems unlikely. Otherwise, I assume some setting in the Client's network settings?

Have you tried using IPX/SPX?

Regards,

Pete

[hal28]

Thanks for the reply Pete.

I'm pretty sure there is no buffering going on in the switch.

I have an ELSA Gladiac 511 PCI graphics card on the client, which I was told would be fine for this purpose by PM and does not exhibit any jerky behaviour. It's just the time delay.

I have not tried IPX/SPX yet, but I'll give that a go when not at day job :(

The log files tend to say that packets got through but took n attempts, where n varies around 10-20 etc. Max frame rate achieved is usually around 30 or so, with average around 8 on a good day.

I have XP Pro on the client, without any service packs. It's just the bare vanilla install from the CD I bought. The client is not accessing the internet so I didn't see the point in service packing it up.

However the Server has been updating automatically (XP Pro) as and when there are updates, (although I have now disabled this as per PM guidance). I wonder if the differences between systems would be a problem?

I'll see what happens under IPX/SPX.

Thanks again,

Hugh

[Pete Dowson]

The log files tend to say that packets got through but took n attempts, where n varies around 10-20 etc.

That's the problem thenthere's something set up wrong somewhere. Such retries only occur when Windows refuses to accept another frame from my modules.

Are these errors occurring in the client, or the server logs, or both?

Max frame rate achieved is usually around 30 or so, with average around 8 on a good day.

Only 8?!!! That's far too low. What sort of processors are you running this on? What is the FS frame rate limiter set to? Your average frame rate recorded at the end of the Wideclient logs should be close to your average FS frame rate. What is the average recorded at the end of the WideServer Log file?

How may Client PCs are there (you mentioned a 5-port hub), and do they all have similar problems and similarly low frame rates? If you only have the two PCs, then it would be more efficient to link them directly, via a cross-over cable, rather than through a hub.

I have XP Pro on the client, without any service packs. It's just the bare vanilla install from the CD I bought.

The current "bare vanilla" CD is up to SP2. Service Pack 1 was included on CDs a long time back. Did you buy it when it was first released?

I would most certainly recommend at least going to SP1 level if you are not there at present. There were all sorts of things wrong with it initially!

The client is not accessing the internet so I didn't see the point in service packing it up.

I'm not sure where Internet access comes into it.

However the Server has been updating automatically (XP Pro) as and when there are updates, (although I have now disabled this as per PM guidance).

Is the Server regularly accessing the Internet whilst you are flying? I would have thought it best for FS performance to keep all that off the FS PC.

I'll see what happens under IPX/SPX.

I'll be releasing my latest Beta versions of FSUIPC and WideFS to the PM support group either later today or tomorrow. You may want to keep an eye out for them there and re-test when you get them.

Regards,

Pete

[hal28]

Hi Pete!

Well I seem to have got things working now :lol:

Something Jonathan from PM said at the end of an email, about the modem causing problems with the TCPIP. I checked the modem config and there were two old entries in their for past modems.

I uninstalled all modems, and reinstalled just the one I need.

Also,

I downloaded the latest graphics drivers from ELSA and installed them on both machines.

I think it was probably the modem config that was causing the problems but maybe a combination.

Anyway, the average throughput on the WideClient is now 21 frames/sec with the FS Frame Rate set at 30 fps. The max achieved was 42 fps.

This seems a lot better and the dials move much much better now.

Thanks very much for help.

Cheers,

Hugh

[Pete Dowson]

Anyway, the average throughput on the WideClient is now 21 frames/sec with the FS Frame Rate set at 30 fps. The max achieved was 42 fps.

This seems a lot better and the dials move much much better now.

That does sound more like it, yes. Glad you resolved it. But you may also want to try the pre-release versions of FSUIPC and WideFS I supplied earlier in the PM support group.

Regards,

Pete

[hal28]

Will give them a go, many thanks.

And at last on with some Flying 8)