kikigey89 Posted August 2, 2010 Report Posted August 2, 2010 Hi there, I have a big problem, with WideFs (Client/Server) I' m building a home cockpit and have several instrumehts running on different PC'S than FS9. Now with WideClient connected to the FS9 (which works) the update Rate of the read data is about 5-10 FPS and therefore too low! The software (JeeHell A320 FMGS) uses about 6% CPU which is very low and the Flghtdirectors coming from the Softwareserver are running at about 30-50 FPS. The data read from FS as mentioned is about 5. Any Idea why? Kind Regards, Chris
Pete Dowson Posted August 3, 2010 Report Posted August 3, 2010 I' m building a home cockpit and have several instrumehts running on different PC'S than FS9. Now with WideClient connected to the FS9 (which works) the update Rate of the read data is about 5-10 FPS and therefore too low! The software (JeeHell A320 FMGS) uses about 6% CPU which is very low and the Flghtdirectors coming from the Softwareserver are running at about 30-50 FPS. The data read from FS as mentioned is about 5. Any Idea why? No, sorry. The WideFS data rate should approximate the FS frame rate, at least up to values like 30 fps. I use Project Magenta with FSX on a 7-PC network, and they all keep up with FSX frames rates locked at 30. If you aren't limiting FS frame rates, try doing so. If FS is running away with the processor WideServer may not get enough time. This is less of a problem on multi-core PCs of course, since WideServer uses different threads. If you check the WideFS logs (WideServer.log in the FS Modules folder, and WideClient.log in your WideClient folder) you might find that there are multiple errors or reconnections, which would certainly cause a severe degradation. If you want to show me, please make sure the logs are complete -- close down FS and WideClient first so that the performance summaries appear at the ends. An FSUIPC log might help too. Regards Pete
kikigey89 Posted August 26, 2010 Author Report Posted August 26, 2010 Sorry for the very late reply. We had an homecockpit event (130 hours online on VATSIM) and because we were able to solve the problem by ourselves we forgot this topic here. A friend of mine gave his WideClient.ini to me and from that point everything was fine. Now I took a look what the differences between the native ini file and his one are: WaitForNewData=500 --> WaitForNewData=50 PollInterval=2000 --> PollInterval=200 That are the only differences and now especially vasFMC runs without jerking and full 30 fps :)
Pete Dowson Posted August 26, 2010 Report Posted August 26, 2010 A friend of mine gave his WideClient.ini to me and from that point everything was fine. Now I took a look what the differences between the native ini file and his one are: WaitForNewData=500 --> WaitForNewData=50 PollInterval=2000 --> PollInterval=200 That are the only differences and now especially vasFMC runs without jerking and full 30 fps :) Strange. Neither of those make sense unless something else is wrong, or that vasFMC program is written very inefficiently in the way it requests data. The WaitForNewData time only gets used when an item of data is first requested. It avoids things going wrong from incorrectly providing default values (generally zero) until the true current values arrive from the Server. Once a program has requested all of its data once, the time out never gets used again, so for this to make any noticeable difference either the connection is being continually re-made, or the program is asking for one item of data at a time over a noticeably long period. The Pollinterval merely controls how frequently the client sends a "dummy" message to the server, in order to reassure the server that it is still operational. Since the server won't time out the Client for something between 10 and 20 seconds, having dummy messages sent 5 times a second, as you are now doing, makes no sense. The values in the INI file have been evolved and tuned for best performance over many years and really should never need adjusting except to make of for problems elsewhere. Didn't you bother to check the WideFS logs as I suggested? Regards Pete
kikigey89 Posted August 27, 2010 Author Report Posted August 27, 2010 Unfortunately not because I got the ini file just 10 minutes after my post here. I have to perform some cockpit software tests today and will record the logs.
kikigey89 Posted August 27, 2010 Author Report Posted August 27, 2010 First of all both log files (client and server) with the native ini file: ********* WideClient Log [version 6.78] Class=FS98MAIN ********* Date (dmy): 27/08/10, Time 12:55:06.468: Client name is CHRISTOPHLAPTOP 12344 Attempting to connect now 13344 Trying to locate server: Need details from Server Broadcast 13344 Failed to connect: waiting to try again 15344 Attempting to connect now 43094 Server = CHRISTOPH 43719 Trying TCP/IP host "CHRISTOPH" port 8002 ... 43719Okay, IP Address = 192.168.1.4 43719 Connection made okay! 137094 New Client Application: "vasfmc" (Id=3628) 243938 ****** End of session performance summary ****** 243938 Total time connected = 199 seconds 243938 Reception maximum: 42 frames/sec, 54168 bytes/sec 243938 Reception average whilst connected: 22 frames/sec, 13451 bytes/sec 243938 Transmission maximum: 12 frames/sec, 1795 bytes/sec 243938 Transmission average whilst connected: 4 frames/sec, 543 bytes/sec 243938 Max receive buffer = 7921, Max send depth = 2, Send frames lost = 0 243938 **************** Individual client application activity **************** 243938 Client 3628 requests: 776 (Ave 3/sec), Data: 6395290 bytes (32137/sec), Average 8241 bytes/Process 243938 ********* Log file closed (Buffers: MaxUsed 3, Alloc 3635 Freed 3635 Refused 0) ********* ********* WideServer.DLL Log [version 6.78] ********* Blocksize guide = 4096 (double allowed) Date (dmy): 27/08/10, Time 12:54:12.921: Server name is CHRISTOPH 73047 Initialising TCP/IP server 73063 Initialising IPX/SPX server 73063 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 73063 Failed to start IPX/SPX Server 73063 Initialising UDP/IP server 74094 Broadcasting service every 1000 mSecs 76297 Incoming connection Accepted ok (skt=9424) TCP 76672 Connected to computer "CHRISTOPHLAPTOP" running WideClient version 6.780 (skt=9424) TCP 276422 Error 10053: client socket disconnected at Client: removing (skt=9424) TCP 284297 Close signalled to clients 285406 Closing down now ... Memory managed: Offset records: 272 alloc, 272 free Read buffer usage: 822 alloc, 822 free, max in session: 1 Write buffer usage: 4787 alloc, 4787 free, max in session: 1 Throughput maximum achieved: 42 frames/sec, 53934 bytes/sec Throughput average achieved for complete session: 7 frames/sec, 4709 bytes/sec Average receive rate from "CHRISTOPHLAPTOP": 3 frames/sec, 515 bytes/sec ********* Log file closed ********* and now with my modified file: ********* WideClient Log [version 6.78] Class=FS98MAIN ********* Date (dmy): 27/08/10, Time 13:02:01.359: Client name is CHRISTOPHLAPTOP 765 Attempting to connect now 1094 Server = CHRISTOPH 1125 Trying TCP/IP host "CHRISTOPH" port 8002 ... 1125Okay, IP Address = 192.168.1.4 1125 Connection made okay! 13547 New Client Application: "vasfmc" (Id=4676) 72515 ****** End of session performance summary ****** 72515 Total time connected = 70 seconds 72515 Reception maximum: 42 frames/sec, 54884 bytes/sec 72515 Reception average whilst connected: 32 frames/sec, 35508 bytes/sec 72515 Transmission maximum: 16 frames/sec, 2318 bytes/sec 72515 Transmission average whilst connected: 13 frames/sec, 1679 bytes/sec 72515 Max receive buffer = 4320, Max send depth = 2, Send frames lost = 0 72515 **************** Individual client application activity **************** 72515 Client 4676 requests: 872 (Ave 12/sec), Data: 6980628 bytes (99723/sec), Average 8005 bytes/Process 72515 ********* Log file closed (Buffers: MaxUsed 3, Alloc 3048 Freed 3048 Refused 0) ********* ********* WideServer.DLL Log [version 6.78] ********* Blocksize guide = 4096 (double allowed) Date (dmy): 27/08/10, Time 13:01:02.734: Server name is CHRISTOPH 40938 Initialising TCP/IP server 40938 Initialising IPX/SPX server 40938 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 40938 Failed to start IPX/SPX Server 40938 Initialising UDP/IP server 42078 Broadcasting service every 1000 mSecs 43719 Incoming connection Accepted ok (skt=9320) TCP 43969 Connected to computer "CHRISTOPHLAPTOP" running WideClient version 6.780 (skt=9320) TCP 115094 Error 10053: client socket disconnected at Client: removing (skt=9320) TCP 120328 Close signalled to clients 121422 Closing down now ... Memory managed: Offset records: 283 alloc, 283 free Read buffer usage: 928 alloc, 928 free, max in session: 1 Write buffer usage: 2401 alloc, 2401 free, max in session: 1 Throughput maximum achieved: 41 frames/sec, 55378 bytes/sec Throughput average achieved for complete session: 9 frames/sec, 10496 bytes/sec Average receive rate from "CHRISTOPHLAPTOP": 12 frames/sec, 1533 bytes/sec ********* Log file closed ********* I recorded videos with both ini files showing vasFMC: Native ini: http://www.christophpaulus.com/files/widefs1.avi Modified ini: http://www.christophpaulus.com/files/widefs2.avi
Pete Dowson Posted August 27, 2010 Report Posted August 27, 2010 Thanks for the logs. There doesn't appear to be anything untoward with WideFS's operations, so I can only think the strange difference is due to domething vasFMC is doing. I've not encountered anything like this before (and WideFS has been going now for about 15 years), so I'm a bit puzzled. Unfortunately the two sessions are not really directly comparable because the original INI session was allowed to run for over 4 minutes whilst the modified INI session only a little over one minute. However, I'll take your word for it that the performance stays the same if allowed to run longer. Assuming that to be the case, the crucial parts of the performance reports appear to be these: Old INI 243938 Reception average whilst connected: 22 frames/sec, 13451 bytes/sec 243938 Client 3628 requests: 776 (Ave 3/sec), Data: 6395290 bytes (32137/sec), Average 8241 bytes/Process Average receive rate from "CHRISTOPHLAPTOP": 3 frames/sec, 515 bytes/sec New INI: 72515 Reception average whilst connected: 32 frames/sec, 35508 bytes/sec 72515 Client 4676 requests: 872 (Ave 12/sec), Data: 6980628 bytes (99723/sec), Average 8005 bytes/Process Average receive rate from "CHRISTOPHLAPTOP": 12 frames/sec, 1533 bytes/sec Seems that this vasFMC is somehow sending requests to the Server at a lot faster rate in the second example. I would really like to know what it is doing which generates this strange difference. There's a lot more logging I could ask you to do to find out, but I think I should try it here to see if I can work it out. So, is "vasFMC" readily available? How would I set it up to use it in the way you are doing? If you could sort me out a "starter pack" for it I will do the investigations on my own systems. Thanks & Regards Pete
kikigey89 Posted August 27, 2010 Author Report Posted August 27, 2010 You can download it on http://www.vas-project.org. The current version is 2.0a9. Unfortunately there is no new version for 1,5 years and it seems that the developers are not interested in continuing their work. So I want to use Jeehell's FMGS (from MyCockpit Forum) in the future. The setup is quite easy: Install vasFMC (installer), maybe AIRAC from Navigraph (also installer) and start vasFMC. I use Airbus style and have made some changes in the settings (MCDU MENU -> SETTINGS) to fit to Airbus behaviour but nothing special. This problem also appeared on the computer of my friend who send me his ini file. So it should also appear on your computer (hopefully). As far as I know the project is open source and you can download the code. Chris
Pete Dowson Posted August 27, 2010 Report Posted August 27, 2010 You can download it on http://www.vas-project.org. The current version is 2.0a9. Ah, that directs me elsewhere, to download sites where it seems I have to become a member. I am a little wary of that. Is there an ordinary download possibility anywhere? Pete
kikigey89 Posted August 27, 2010 Author Report Posted August 27, 2010 Ah, you are right, they changed the download location "due to high traffic" (who knows...). I can send it to you via mail. What is your mail adsress?
Pete Dowson Posted August 27, 2010 Report Posted August 27, 2010 Ah, you are right, they changed the download location "due to high traffic" (who knows...).I can send it to you via mail. What is your mail adsress? petedowson@btconnect.com Thanks! Pete
Pete Dowson Posted August 29, 2010 Report Posted August 29, 2010 Back to this: ... we were able to solve the problem by ourselves we forgot this topic here.A friend of mine gave his WideClient.ini to me and from that point everything was fine. Now I took a look what the differences between the native ini file and his one are: WaitForNewData=500 --> WaitForNewData=50 PollInterval=2000 --> PollInterval=200 That are the only differences and now especially vasFMC runs without jerking and full 30 fps :) I've had a chance to run vasFMC now to see why there's any difference, but I cannot reproduce your results. vasFMC seems completely limited by its own performance problem, not by WideFS, and the logs for both INI settings show identically. The misleading increase in transmission rates (i.e. TO the Server) happens simply because of the polling rate being changed to 200 mSecs (5 per sec) instead of 2000 (1/2 per sec). The frame rate of FS on my Server was around 39-40. WideClient with vasFMC on my Client PC ran at 25-28 fps (depending on how much logging I asked WideClient to do). What I do notice from the logs is that vasFMC requests large areas of FSUIPC offsets, areas which include non-populated and unpredictable values. On FSUIPC3 this is very inefficient as it makes FSUIPC call lots of routines in FS to obtain values which are either useless or which are unlikely to be used by vasFMC. On FSUIPC4 it is less of a problem because the offsets are all within FSUIPC's own address space. With all of the possible vasFMC windows displayed I found it extremely unresponsive -- entering ABC in the CDU's scratchpad shows nothing for a few seconds, before the letters appeared. I can't believe it is like this on your PC, so something is evidently wrong. I notice the package you sent me announces itself as an Alpha test version. Is that right? Is there some configuring I ought to be doing? I think that unless I can get its performance to be reasonable, there's no way of determining what possible affect any WideClient parameters can have. It's all swallowed by vasFMC sitting unresponsively. Regards Pete
kikigey89 Posted August 30, 2010 Author Report Posted August 30, 2010 Strange... I installed vasFMC again a week ago because I had to write an article for a German flightsim magazine in which I test JeeHell's FMGS and vasFMC. After setup I had just to make some changes in MCDU MENU - SETTINGS to fit to Airbus behaviour. That were the only things. But somewhere in the settings you can display the framerate of vasFMC. From my homecockpit I know that vasFMC has some problems with its FSUIPC offsets. Sometimes it ignores changes of switches. You can see how the FSUIPC offset changes but vasFMC ignores it. Also a reason why I will change to JeeHell's FMGS in the next months. Yes, vasFMC is an alpha version. But the development on it stopped already in 2008. If you ask in their forum when the next version will be released they say "It's done when it's done". I think there will be no more version in the future. Something is going on there but I don't know what...
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