Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hi Pete, I'm having a strange problem when using WideFS with the Project Magenta Airbus software. I'm running the PM software on a new high end machine with 2 monitors, I'm running FS on another high end machine. Performance is not my problem, both machines perform exceptionally well and I've had no problems running the software or FS. I'm using the latest FSUIPC and WideFS from your site for FS9.

I load up FS then start WideFS and all the PM software as normal and everything is running fine, FS is running smoothly with a constant locked 40fps, all the PM software is running as it should. After approximately 30 minutes I start getting small stutters in FS, these small stutters grow and grow and it turns into a slideshow after an hour or so. My FPS are still showing 40 but sharp drops with the stutters. I've monitored the memory consumption on my FS machine and everything still looks good and stable - plenty of memory and CPU left. Funnily enough the GC software on my other machine still runs perfectly without any stutters although the FS data rate drops from the normal 40 or so to around 8.

As soon as I close WideFS on my client machine the stutters totally disappear instantly. I am then able to reconnect and fly with no stutters until a further 30 minutes. I've tried changing cables and even network cards but it still happens. I'm using static IP addresses and a Lynksys router sharing my internet connection. I've tried all the networking optimising tips in the PM documentation with no luck. I've been using WideFS for years now and never seen anything that resembles this problem, it's only happening when I use PM software.

Could I have some setting wrong - I've tried quite a few tips found on the forum and the documentation. I'm just hoping you have heard of this problem before and can help!

Thanks

Ben

Posted
I've monitored the memory consumption on my FS machine and everything still looks good and stable - plenty of memory and CPU left.

Hmm .. it does sound very much like something isn't performaing fast enough and a queue is building up. If it isn't to do with memory buffers than it just has to be something else en route to the Client PC.

Do the Client or Server Logs show any problems at all? What versions of everything are you using?

Funnily enough the GC software on my other machine still runs perfectly without any stutters although the FS data rate drops from the normal 40 or so to around 8.

Is there a delay is things happening in the Sim and being reflected in the GC? If so something is queing. If not thenI don't know. Something's going strange in the FS PC.

I've been using WideFS for years now and never seen anything that resembles this problem, it's only happening when I use PM software.

What are the OpenGL graphics frame rates shown by the PM GC on the client? Are you sure you are not trying to drive the client too fast?

40 fps as an average is quite high for a PM networked system, though it should cope okay. As an experiment try limiting the FS frame rate to, say, 25 fps, and see if that makes a difference to how long it goes or whether it starts stuttering at all.

What protocol are you using -- TCP, UDP or IPX? It may be worth trying a different one.

Regards

Pete

Posted
Do the Client or Server Logs show any problems at all? What versions of everything are you using?

I'm at work now but I'll do a test flight tonight and have a look. I'm using FSUIPC 3.70 and WideFS 6.70.

Is there a delay is things happening in the Sim and being reflected in the GC? If so something is queing. If not thenI don't know. Something's going strange in the FS PC.

No delay at all really, everything is running quickly just the stutters in FS. I tried doing a 4 hour flight over the weekend with the LDS 767 and Activesky /SB3 over WideFS and had no stutters what so ever.

What are the OpenGL graphics frame rates shown by the PM GC on the client? Are you sure you are not trying to drive the client too fast?

OpenGL framerates are usually in the 110-140 region.

As an experiment try limiting the FS frame rate to, say, 25 fps, and see if that makes a difference to how long it goes or whether it starts stuttering at all.

I've already tried that, it still happens at the same rate.

What protocol are you using -- TCP, UDP or IPX? It may be worth trying a different one.

I've tried TCP and IPX so far witht he same results, I'll try UDP tonight.

What I can't get my head around is why FS seems to be suffering with the stutters - something has got to be building up as it's fine at first. Hopefully something shows up in the logs.

Thanks for the swift support.

Posted

Hi Ben

Did you all the settings described in PM-Manual ?

Like:

Here is a list of tips to make sure your network runs as fast as possible... this mostly applies to XP systems because they seem to be the most popular ones:

- avoid any "Auto" settings in the network "LAN Settings" for the Link

Speed / Duplex, e.g. use "100 Full Duplex" rather than "Auto"

- Set the "receive Buffer" of your network card as high as possible

- Disable the "Allow Indexing Service to index this disk..." in your "Local

Disk Properties", as it really slows down network file transfer

- Limit your FS frame rate, avoid "unlimited" 30 FPS should be enough for

most, use 50 fps if you must and your hardware can handle it. High or

Unlimited settings will leave WideServer very little time to process

network traffic and will result in pauses in the connected programs.

- turn off automatic updates

- assign an IP address for every machine, do not use automatic settings

for that

- disable network authentication IEEE 802

- if you have control, turn off system restore disable automatic syncronize

internet time

Best Regards

Thomas Richter

Posted

Hi Thomas thanks, I've tried all those tips and hints and nothing solves the problem!

Here is a log from my flight tonight from EDDF-EGLL, about 30 mins in my performance degrades to stuttering. As soon as I disconnected WideFS my stutters vanished.

Here are the logs:

********* WideClient Log [version 6.70] Class=FS98MAIN *********

Date (dmy): 08/11/06, Time 19:23:45.265: Client name is SECOND

94 Attempting to connect now

297 Server = MAIN

297 Trying TCP/IP host "MAIN" port 8002 ...

297Okay, IP Address = 192.168.1.102

312 Connection made okay!

17484 New Client Application: "abgc" (Id=2976)

40062 New Client Application: "FCU" (Id=2544)

48391 New Client Application: "pmsystems" (Id=1712)

67656 New Client Application: "mcdu" (Id=3044)

235656 New Client Application: "squawkbox" (Id=3340)

295125 New Client Application: "ASv6" (Id=3876)

4330641 WRITESTATEDATA received with bad data size!

4330641 0 ReadLocal: Offset=1001507A, Size=1021B

6316672 ****** End of session performance summary ******

6316672 Total time connected = 6316 seconds

6316672 Reception maximum: 64 frames/sec, 37091 bytes/sec

6316672 Reception average whilst connected: 50 frames/sec, 509 bytes/sec

6316672 Transmission maximum: 65 frames/sec, 9425 bytes/sec

6316672 Transmission average whilst connected: 49 frames/sec, 258 bytes/sec

6316672 Max receive buffer = 8174, Max send depth = 10, Send frames lost = 0

6316672 **************** Individual client application activity ****************

6316672 Client 2976 requests: 208073 (Ave 32/sec), Data: 643320265 bytes (101855/sec), Average 3091 bytes/Process

6316672 Client 2544 requests: 202134 (Ave 32/sec), Data: 281690806 bytes (44599/sec), Average 1393 bytes/Process

6316672 Client 1712 requests: 35957 (Ave 5/sec), Data: 111246723 bytes (17613/sec), Average 3093 bytes/Process

6316672 Client 3044 requests: 53471 (Ave 8/sec), Data: 103971984 bytes (16461/sec), Average 1944 bytes/Process

6316672 Client 3340 requests: 38478 (Ave 6/sec), Data: 2234209 bytes (353/sec), Average 58 bytes/Process

6316672 Client 3876 requests: 30377 (Ave 4/sec), Data: 2283264 bytes (361/sec), Average 75 bytes/Process

6316672 ********* Log file closed (Buffers: MaxUsed 13, Alloc 889097 Freed 889097 Refused 0) *********

-----------------------------------------------

********* WideServer.DLL Log [version 6.70] *********

Blocksize guide = 4096 (double allowed)

Date (dmy): 08/11/06, Time 19:20:30.375: Server name is MAIN

196766 Initialising TCP/IP server

196766 Initialising IPX/SPX server

196766 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

196766 Failed to start IPX/SPX Server

196766 Initialising UDP/IP server

198094 Broadcasting service every 1000 mSecs

202609 Incoming connection Accepted ok (skt=2808) TCP

202688 Connected to computer "SECOND" running WideClient version 6.700 (skt=2808) TCP

6518953 Error 10053: client socket disconnected at Client: removing (skt=2808) TCP

6524750 Close signalled to clients

6525844 Closing down now ...

Memory managed: Offset records: 10421 alloc, 10421 free

Read buffer usage: 119743 alloc, 119743 free, max in session: 1

Write buffer usage: 321271 alloc, 321271 free, max in session: 1

Throughput maximum achieved: 64 frames/sec, 37242 bytes/sec

Throughput average achieved for complete session: 24 frames/sec, 11110 bytes/sec

Average receive rate from "SECOND": 18 frames/sec, 3654 bytes/sec

********* Log file closed *********

Cheers

Ben

Posted

6316672 Reception average whilst connected: 50 frames/sec, 509

Two things to note there.

1. 50 fps for Widefs is very very high for an average. What sort of super-processor is ther Server? What is your FS frame rate limiter set to?

2. Have you tried using UDP protocol at all, to see if it is something in the TCP/IP part of the Windows drivers?

You say there's no apparent latency in the actions on the Clients, so it isn't queuing problems. I can only think that somehow the Network parts of Windows, on the Server, are getting far too much of the processor time.

Can I see the INI files too please?

There are parameters which can slow down WideServer, but there's not been a case needing their use in many years.

I must admit never to having seen a case quite like this before, not in the seven years or more of WideFS! It's rather puzzling.

Regards

Pete

Posted

Hi Pete I'm running a fast FS computer but because I don't use Add on scenery and don't like Autogen on I usually get a FPS of around 70/80fps so tend to lock at 50 or so. I have tried locking the FPS all the way down tp 25fps but I still get this problem at the same rate.

Here are my Ini Files:

Client:

[Config]

Port=8002

Window=32000,32000,160,34

Visible=Yes

ServerName=MAIN

ButtonScanInterval=20

ClassInstance=0

NetworkTiming=5,1

MailslotTiming=2000,1000

PollInterval=2000

Port2=9002

ResponseTime=18

ApplicationDelay=0

TCPcoalesce=No

WaitForNewData=500

MaxSendQ=100

OnMaxSendQ=Log

NewSendScanTime=50

Priority=3,1,2

; -----------------------------------------------

[user]

Log=Errors+

KeySend1=RWon

KeySend2=RWoff

; ===============================================

Server:

; PLEASE SEE the documentation for parameter details

; ==================================================

[Config]

Port=8002

AdvertiseService=1

AutoRestart=0

AutoUpdateTime=13

MaximumBlock=4096

NoStoppedRestarts=Yes

Port2=9002

RestartTime=10

SendTimeout=15

TCPcoalesce=No

; -----------------------------------------------

[user]

Log=Errors+

; ===============================================

[ClientNames]

1=HEWITT1

2=SECOND

EDIT: Not tried UDP - I will certainly give it a go.

Cheers

Posted

Hi Pete after re-reading this post this morning I noticed that my Server ini reads:

[ClientNames]

1=HEWITT1

2=SECOND

HEWITT1 was my old name for my Client PC (named SECOND now) - I wonder why it is showing up still? Could it be that in some way my server PC is receiving all the data from WideFS twice? I tried deleting the info from the ini file but that old client name still shows up! I have no idea how to get rid of it.

Posted
Hi Pete after re-reading this post this morning I noticed that my Server ini reads:

[ClientNames]

1=HEWITT1

2=SECOND

HEWITT1 was my old name for my Client PC (named SECOND now) - I wonder why it is showing up still?

If you've never deleted the INI file since you changed the name, it would still be listed. It does no harm. WideFS keeps track of things so it can number buttons, as I said.

Could it be that in some way my server PC is receiving all the data from WideFS twice? I tried deleting the info from the ini file but that old client name still shows up! I have no idea how to get rid of it.

Really? WideServer cannot guess at such a name -- it must actually see the connection and LOG it for it to be added. Check the Log.

Might you have more than one Network connection?

Anyway, back on performance, you can experiment with the "AutoUpdateTime" parameter in WideServer.INI to change the performance of the WideFS operation. Smaller number = faster scan, larger = slower. Try different values, like 4, 8, 20, 30, 50.

Regards

Pete

Posted

Hi Pete, problem solved!!

The "AutoUpdateTime" did it, I changed it a few times and found 40 to be the sweet spot. Everything runs as smooth as silk now - no stuttering and great performance all around.

Thanks for you help.

Ben

Posted

The "AutoUpdateTime" did it, I changed it a few times and found 40 to be the sweet spot. Everything runs as smooth as silk now - no stuttering and great performance all around.

Good! Thanks for letting me know.

It is strange, but I've never heard of a need to change that value before. It's something for me to think about -- in the recent WideFS documentation update I've more or less relegated all that to a Technical document not really meant to be used much, hopefully. Maybe I ought ot mention your problem and solution more prominently in the Troubleshooting section at least.

Regards

Pete

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.