Ralph Posted March 24, 2009 Report Share Posted March 24, 2009 Been working with the PM people for a couple of weeks on this one and they suggested that I post here. Network of 7 identical PCs running the PM suite. Pentium D 2GHz CPU 1GB RAM 10/100 Network card @ 100Mbps full duplex Nvidia Geforce 9600 GSO graphics card Only software running is PM app and WideFs FS2004 PC Intel Core 2 @ 2.66 GHz 2GB RAM Intel Pro 1000 Network card @ 100Mbps full duplex Nvidia Geforce 8800 GTS graphics card Only software running is FS2004 and Flight Illusion interface app No extra scenery or weather software, just basic FS2004 whilst I build the sim Windows XP Pro SP3 on all PCs No Firewalls and No AV software running on any PCs Netgear 16 port 10/100/1000 switch Using TCPIP WideFS version 6.78 FSUIPC version 3.85 Problem Pauses occur and are visible on the PFD/ND screeens when there is about to be a change. Example would be when a waypoint is just about reached, there is a pause for about 2 seconds-sometimes more. When speed changes from climb to cruise, or cruise to descent there is a pause. So, it seems that anything to do with the CDU "sending instructions" causes a pause. I can re-create these pauses - as an example, I can enter a flap/speed setting in the CDU whilst in the cruise and everything pauses for about 2 seconds. WideServer log ********* WideServer.DLL Log [version 6.78] ********* Blocksize guide = 4096 (double allowed) Date (dmy): 24/03/09, Time 23:11:22.359: Server name is FS9 15922 Initialising TCP/IP server 15953 Initialising IPX/SPX server 15953 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 15953 Failed to start IPX/SPX Server 15953 Initialising UDP/IP server 16031 Broadcasting service every 1000 mSecs 16031 Preferred protocol = TCP 17547 Incoming connection Accepted ok (skt=2924) TCP 17828 Connected to computer "FDSERVER" running WideClient version 6.780 (skt=2924) TCP 18547 Incoming connection Accepted ok (skt=2956) TCP 18547 Incoming connection Accepted ok (skt=2948) TCP 18625 Connected to computer "CDU" running WideClient version 6.780 (skt=2948) TCP 18718 Connected to computer "CAPTND" running WideClient version 6.780 (skt=2956) TCP 244906 Close signalled to clients 246015 Closing down now ... Memory managed: Offset records: 508 alloc, 508 free Read buffer usage: 1607 alloc, 1607 free, max in session: 1 Write buffer usage: 16586 alloc, 16586 free, max in session: 1 Throughput maximum achieved: 75 frames/sec, 3246 bytes/sec Throughput average achieved for complete session: 30 frames/sec, 1242 bytes/sec Average receive rate from "FDSERVER": 0 frames/sec, 24 bytes/sec Average receive rate from "CAPTND": 0 frames/sec, 28 bytes/sec Average receive rate from "CDU": 6 frames/sec, 1118 bytes/sec ********* Log file closed ********* Wideclient log (CDU) ********* WideClient Log [version 6.78] Class=FS98MAIN ********* Date (dmy): 24/03/09, Time 22:44:09.015: Client name is CDU 172 Attempting to connect now 1172 Trying to locate server: Need details from Server Broadcast 1172 Failed to connect: waiting to try again 3219 Attempting to connect now 68047 Trying to locate server: Need details from Server Broadcast 1639531 Server = FS9 1639531 Trying TCP/IP host "FS9" port 8002 ... 1639531Okay, IP Address = 192.168.1.30 1639531 Connection made okay! 1639859 c:\CDU 1639859 c:\CDU\cdu.exe 1643797 New Client Application: "cdu" (Id=400) 1860375 Received shutdown offset code = ADBC 1860375 FS closing down (param=ADBC), disconnecting 1860375 ********* Interim performance summary ********* 1860375 Total time connected so far = 220 seconds 1860375 Reception maximum so far: 26 frames/sec, 845 bytes/sec 1860375 Reception average whilst connected so far: 23 frames/sec, 638 bytes/sec 1860375 Transmission maximum so far: 8 frames/sec, 1687 bytes/sec 1860375 Transmission average whilst connected so far: 6 frames/sec, 1154 bytes/sec 1860375 Max receive buffer = 564, Max send depth = 3, Send frames lost = 0 1860375 **************** Individual client application activity **************** 1860375 Client 400 requests: 1422 (Ave 6/sec), Data: 2977715 bytes (13535/sec), Average 2094 bytes/Process 1860375 *********************************************** 1860469 Received shutdown offset code = ADBC 1867000 Connection closed by server! 1867000 Attempting to connect now 1879016 Giving up server, looking for another! Wideclient log (Captain PFD/ND) ********* WideClient Log [version 6.78] Class=FS98MAIN ********* Date (dmy): 24/03/09, Time 22:44:15.156: Client name is CAPTND 172 Attempting to connect now 1172 Trying to locate server: Need details from Server Broadcast 1172 Failed to connect: waiting to try again 3203 Attempting to connect now 68000 Trying to locate server: Need details from Server Broadcast 1639735 Server = FS9 1639735 Trying TCP/IP host "FS9" port 8002 ... 1639735Okay, IP Address = 192.168.1.30 1639735 Connection made okay! 1640094 c:\PFD 1640094 c:\PFD\pfd.exe 1645953 New Client Application: "pfd" (Id=660) 1860563 Received shutdown offset code = ADBC 1860563 FS closing down (param=ADBC), disconnecting 1860563 ********* Interim performance summary ********* 1860563 Total time connected so far = 220 seconds 1860563 Reception maximum so far: 25 frames/sec, 973 bytes/sec 1860563 Reception average whilst connected so far: 23 frames/sec, 645 bytes/sec 1860563 Transmission maximum so far: 2 frames/sec, 1172 bytes/sec 1860563 Transmission average whilst connected so far: 0 frames/sec, 30 bytes/sec 1860563 Max receive buffer = 820, Max send depth = 2, Send frames lost = 0 1860563 **************** Individual client application activity **************** 1860563 Client 660 requests: 11180 (Ave 50/sec), Data: 39760130 bytes (180727/sec), Average 3556 bytes/Process 1860563 *********************************************** 1860656 Received shutdown offset code = ADBC 1867203 Connection closed by server! 1867203 Attempting to connect now 1879219 Giving up server, looking for another! Wideserver ini [Config] ProtocolPreferred=TCP Port=8002 AdvertiseService=1 AutoRestart=0 AutoUpdateTime=13 MaximumBlock=4096 NoStoppedRestarts=Yes Port2=9002 RestartTime=10 SendTimeout=15 TCPcoalesce=No ; ----------------------------------------------- [user] Log=Errors+ AllowShutdown=Yes ; =============================================== [ClientNames] 1=FDSERVER 2=FIRSTOFFICERND 3=CAPTND 4=EICAS 5=MCP 6=CDU 7=RCDU Wideclient ini [Config] Port=8002 Window=32000,32000,160,34 Visible=Yes 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+ ;RunReady1=C:\Sim-Avionics\CDU\CDU.exe ;RunReady2=C:\Sim-Avionics\CDU_FirstOfficer\CDU.exe RunReady1=c:\CDU\cdu.exe AllowShutdown=Yes Help anyone ? Thanks Ralph Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 25, 2009 Report Share Posted March 25, 2009 FSUIPC version 3.85 That FSUIPC version is out of date and unsupported. Not that I can see it makes any difference. And there is no problem with the WideFS links shown in the logs. Did you check the FSUIPC log too, to make sure no errors are reported in its communications with FS? Pauses occur and are visible on the PFD/ND screeens when there is about to be a change. Example would be when a waypoint is just about reached, there is a pause for about 2 seconds-sometimes more. When speed changes from climb to cruise, or cruise to descent there is a pause. So, it seems that anything to do with the CDU "sending instructions" causes a pause. I can re-create these pauses - as an example, I can enter a flap/speed setting in the CDU whilst in the cruise and everything pauses for about 2 seconds. Everything? Or just the PM instrumentation? Surely no FS pauses? It sounds to me as if there are problems with CDU access via its file operations. Maybe your folder, specified in the CDU INI for its access, is situated badly? It would be best on the CDU PC, not on the FS PC where disk access may be slower because of FS needs. Don't forget that a lot of PM's communications relies on simple file sharing access over the network, it isn't all FSUIPC/WideFs related. The only other possibility i can think of relates to graphics drivers on the PFD/ND PCs, but if this was the case i would expect them to occur any time, not just when there's a CDU update. Regards Pete Link to comment Share on other sites More sharing options...
Ralph Posted March 25, 2009 Author Report Share Posted March 25, 2009 Thanks for the swift reply. >>>That FSUIPC version is out of date and unsupported. I'll update to 3.90 >>>Not that I can see it makes any difference. And there is no problem with the WideFS links shown in the logs. Did you check the FSUIPC log too, to make sure no errors are reported in its communications with FS? No, but I will check the logs >>>Everything? Or just the PM instrumentation? Surely no FS pauses? You are correct, just PM >>>It sounds to me as if there are problems with CDU access via its file operations. Maybe your folder, specified in the CDU INI for its access, is situated >>>badly? It would be best on the CDU PC, not on the FS PC where disk access may be slower because of FS needs. Don't forget that a lot of PM's >>>communications relies on simple file sharing access over the network, it isn't all FSUIPC/WideFs related. CDU files are situated on the CDU PC, as recommended by PM, but I will check again, (for the hundredth time!!), that this is correct and file sharing is OK. I'm going to be really cheesed off if it's file sharing! >>>The only other possibility i can think of relates to graphics drivers on the PFD/ND PCs, but if this was the case i would expect them to occur any time, not just when there's a CDU update. Agreed and I had already checked the graphic cards and drivers At least I have comfort that widefs logs show no problems and I'll now look elswhere. Thanks again. Regards Ralph Link to comment Share on other sites More sharing options...
avan1001 Posted March 27, 2009 Report Share Posted March 27, 2009 Hi Pete, Will the UDP protocoll improve connections between computers as regards PM software ? Kind regards Tony Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 27, 2009 Report Share Posted March 27, 2009 Will the UDP protocoll improve connections between computers as regards PM software ? For WideFS traffic? Yes, unless your Network is having problems. UDP has none of the checks and retries incorporated into TCP. Less red-tape, less checking. it is noticeable smoother providing your system is working well. If it isn't working well you will get lost data blocks which could make things jerky (for displays) or non-responsive (for switches). Oh, and don't use UDP if your network is in a loop instead of a star. Looped networks are common if you are using FireWire connections instead of Ethernet. The problem with loops, or any setup where there's more than one route between any two of the PCs, is that UDP does not guarantee the ORDER in which things arrive. This doesn't matter on an ordinary star arrangement (i.e. a hub with spokes). I know all this because my cockpit network was originally a firewire loop and I had to sort out what was going on when I tried UDP. Now I use an Ethernet star (with only the RCDU connected to the CDU by firewire) I am using UDP very successfully. Definitely smoother-looking especially with FSX, and I don't have to limit FS's framerate which is definitely a bonus with DX10 mode. Regards Pete Link to comment Share on other sites More sharing options...
avan1001 Posted March 27, 2009 Report Share Posted March 27, 2009 Sounds good Pete. Are there any specific settings required/recommended by you ? Can I just change protocoll in FSUIPC and WIDEFS ini.files ? Kind regards Tony Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 27, 2009 Report Share Posted March 27, 2009 Are there any specific settings required/recommended by you ? No. Can I just change protocoll in FSUIPC and WIDEFS ini.files ? If your Clients are connecting automatically (i.e. you've not specified the Server or Protocol in each Wideclient.INI file, then all you need to do is set "ProtocolPreferred=UDP" in the Server parameters (in FSUIPC4.INI or WideServer.INI, whichever applies). However, if you are making your Clients connect explicitly, then just change the Protocol parameter in each WideClient.INI -- no change on the Server as it automatically supports TCP, UDP, and IPX (if installed). Regards Pete Link to comment Share on other sites More sharing options...
Ralph Posted April 2, 2009 Author Report Share Posted April 2, 2009 Problem solved! All my network cards were set to 100Mbps/Full Duplex as recommended. I changed them all to "Auto" and the pauses disappeared. I guess some network cards don't like being told what to do :) Regards Ralph Link to comment Share on other sites More sharing options...
Pete Dowson Posted April 2, 2009 Report Share Posted April 2, 2009 All my network cards were set to 100Mbps/Full Duplex as recommended. I changed them all to "Auto" and the pauses disappeared. I guess some network cards don't like being told what to do :) Thanks for letting us know! Regards Pete Link to comment Share on other sites More sharing options...
Farrokh Posted October 7, 2009 Report Share Posted October 7, 2009 hi - I've had the same issues and have switched to a gigabit network on all PC's/switch - this has made it much better.... I've noticed that the "mini pause" happened when there was a change of graphic data - ie, if I selected WXR or STA on the efis - anyway, the gigabit seems to have taken care of it - looks like a network card / setting thing... Farrokh. Link to comment Share on other sites More sharing options...
Pete Dowson Posted October 7, 2009 Report Share Posted October 7, 2009 ... looks like a network card / setting thing... Can be. Those WXR and STA buttons cause the PFD program to go find data separately from WideFS too, of course, maybe from its own files on the local disk, so disk access speeds and local fragmentation may come into it too. For WideFS, if you have a good reliable network connection (check logs for no errors), and with no loops (i.e. only one route to each PC from the Server), then the UDP protocol is definitely preferred over TCP. It has no checking and is faster as a result. Regards Pete Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now