CPU-Cycles WideClient

[jjjanezic]

Good morning,

I always develop my software on my laptop, connected to my FS-PC via FSUIPC/WideFS.

I now tried to do it the other way around (FS on Laptop, Visual Studio on PC) because the PC's screen is larger.

Well I did it all right (Serveripaddr in client.ini - nothing else), everything works ("Connected" appears), but then WideClient (now on PC) needs almost all CPU-Cycles (about 96% - changing of course)

Any idea what I've done wrong?

Of course I tried to change it back, and it works perfectly.

The I had a look into the log-file and found this:

********* WideClient.DLL Log [version 6.221] Class=FS98MAIN *********

Date (dmy): 10/06/04, Time 08:30:04.371: Client name is MAINPC

40 Attempting to connect now

50 Connection made okay!

20119 Timed out response: connection assumed lost!

20129 Ready to try connection again

20169 Attempting to connect now

20179 Connection made okay!

23744 Reception maximum achieved: 0 frames/sec, 0 bytes/sec

23744 Reception average achieved whilst connected: 0 frames/sec, 18 bytes/sec

23744 Max receive buffer = 30, Max send depth = 0

23744 ********* Log file closed (Buffers: MaxUsed 1, Alloc 6 Freed 6 Refused 0) *********

It seems that it has lost the contact. But - as I said - the other way around it works perfectly....

I work with the V6.221.

Thanks,

Joachim

mamber of http://www.a320flightdeck.com

[Pete Dowson]

Well I did it all right (Serveripaddr in client.ini - nothing else), everything works ("Connected" appears), but then WideClient (now on PC) needs almost all CPU-Cycles (about 96% - changing of course)

What do you mean by "needs"? For instance, depending on PC type and some other things, FS "needs" 100% of PC cycles. I think "uses" is a better word than "needs" -- it soaks up idle time. You can only determine whether it "needs" those by seeing if other things run as well without it stopping or slowing significantly.

Apart from calls from applications, WideClient also works off calls to it from Winsock (the network part of Windows), plus a 'watchdog' timer (WM_TIMER) message to keep track of responses. Between them these determine how much time it uses.

Quite honestly I cannot understand why you are looking at CPU usage in any case. What is the actual problem you are trying to resolve? CPU usage is not a problem in itself -- it may help determine what is going on when there is a problem, but should otherwise be completely ignored.

20179 Connection made okay!

23744 Reception maximum achieved: 0 frames/sec, 0 bytes/sec

It seems that it has lost the contact.

No, there's nothing shown wrong there -- it often happens that WideFS takes two tries to connect, as here, because of initial setup exchanges. That is nothing to worry about and only occurs in the first few seconds. It was perfectly connected at 20179 (20 seconds after loading), but then for some strange reason you closed it down almost immediately (23744, less than 4 seconds later), before anything but its own protocol data checks had been exchanged. Why bother to load it if you aren't using it?

After loading WideClient try running your application program.

Regards,

Pete

[jjjanezic]

Hi, thx for your answer.

Well, "needs" in this context means, that my Visual Studio runs very slow, because it only gets the rest 3% of CPU-Time (that's the reason why I was looking for CPU-Cycles).

It's so slow, that it is not possible to work anymore. For example entering a charcter via keyboard needs about 2 seconds to appear on screen.

If I do it the other way around, there is no problem at all....Then I have about 5% for Visual Studio, almost zero for WideClient and 95% of "empty cycles" (I don't know the proper English word for it, but I'm sure you know what I mean).

If - according to the log-file - the network is not the problem, what could it be else?

THX,

[Pete Dowson]

Well, "needs" in this context means, that my Visual Studio runs very slow, because it only gets the rest 3% of CPU-Time (that's the reason why I was looking for CPU-Cycles).

It's so slow, that it is not possible to work anymore. For example entering a charcter via keyboard needs about 2 seconds to appear on screen.

Ah, right. In that case something is very much amiss.

If - according to the log-file - the network is not the problem, what could it be else?

Well if it is only happening when Wideclient is running, then it must be the network, but it doesn't appear to be coming through to WideClient in any sort of failure report. Mind you, with less than 4 seconds of operation and apparently no application running, Wideclient wouldn't have had anything much to do in any case. When you actually run a WideClient application does that run normally or slow? Are there any errors in the Log then?

Don't just look at the Client log -- there may be problems reported at the Server end.

I really don't know what else to suggest. If you are using a Network card, try swapping it, or try uninstalling it and reinstalling it. See if there are later drivers, and so on. With no actual errors I can't understand what is holding things up, and as you say the same Network card and drivers operate okay when it is playing the part of the Server instead. Most odd.

I think you may need to find a Network expert for this if you can't track it down yourself. Try Katy Pluta ober in the FS2004 Forum. She's been able to help me several times.

Regards,

Pete

[jjjanezic]

THX for your very fast answer. Really perfect service.

[airforce2]

I'd be taking a hard look at the timing settings in WideClient if I saw 94% CPU ute rate.

Cheers

Bob

[Pete Dowson]

I'd be taking a hard look at the timing settings in WideClient if I saw 94% CPU ute rate.

The defaults should be okay. There aren't any you can change which would affect CPU usage -- mostly they control things like whether the client sleeps a bit before returning control to the client application -- this is designed to prevent the applications hogging the processor, and in effect gives processor time away. But even setting that specific timeout to zero (so there are no such sleeps) should only mean the application is getting more time, not WideClient. When there's no application running Wideclient will be idling, just waking up to receive frames from the Server and, on timer calls, to send one to show it is still there.

Certainly, though, you are right that I ought to have checked the INI files he is using -- I suppose I assumed he would leave them to default.

Regards,

Pete

[vdkeybus]

jjjanezic,

Another possible problem is RAM shortage. I'm doing a comparable thing as you (albeit I'm using Borland C++ Builder). Luckily BCC is quite small, but especially when running FS2004 (instead of FS2002), I experience the symptoms you're talking about. It happened once that I had to wait one minute (!) before a key got accepted, because Windows was apparently doing a major rearrangement of the memory resources. My notebook is a P4 2.4GHz with 512 MB of RAM.

Try and find out which application is hogging the CPU and also look at the peak memory usage.

J.

[CATIII]

I experienced the same on WinXP Home. After startup, Wideclient used 99% of CPU time and took ~30-50 seconds until normal operation was possible. During this period it logged the message "connection assumed lost..." exactly 4 times.

Installing Win2000 helped a lot. Wideclient now connects immediately within 1 or 2 seconds. Nevertheless I can reproduce the above behaviour when artificially crashing my application (which runs on top of Wideclient):

Although Wideclient seems to survive the crash (no log entries), my restarted application reports: "Maybe running on WideClient, but FS not running on Server, or wrong FSUIPC". Wideclient then needs another 40 seconds and thereafter a FSUIPC_Open() is successful. I suspect that Wideclient is somehow confused or waiting if some operation with FSUIPC_Read() or FSUIPC_Write() was interrupted unexpectedly.

Just wanted to let you know that other builders face similar problems :-) Unfortunately I don't have a direct solution but I suggest switching to Win2000 which solved many other small problems, too.

Michael

PS: Sometimes my application also crashes due to programming faults ;-)

[jjjanezic]

Hello Michael,

that's good news, because all the other resolution advices are not that helpful (system got enough RAM, all drivers the newest etc...)

But your message fits perfectly in my situation because on the PC I've installed WIN2000 and on the notebook XP.

Thanks,