Wideclient eating CPU cycles

[Bruce_N]

Pete,

Hope you had a good holiday.

I've got a problem with wideclient taking 99% of the CPU cycles, even when nothing is operating across the network.

Here's the background.

I run a registered WideFS 6.51 across two desktop computers running on WinXP SP2, both on the same home network subnet (plugged into the same router) using the same network workgroup name. The wideclient 6.5.1 system has been operating perfectly until about 2 weeks ago. Suddenly, upon starting wideclient, I noticed that the applications running via wideclient were showing no connection to FS, even though WideFS was indicating a connection.

Opening task manager, wideclient was using 99% of the CPU and choking off the other apps. What is so puzzling is that this was a sudden change and wideclient worked so well before, hardly using 1% of the CPU, if that!

I have deleted wideclient and reinstalled it, fiddled with the INI file, but nothing seems to help. I have 2 other desktop systems and a laptop, all running WinXP SP2, and wideclient works as expected on these other systems. Therefore, I think I can eliminate wideserver as the problem.

I am using FSUIPC 3.60 on the FS computer.

Here is the log from wideclient on the problem computer:

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

Date (dmy): 14/05/06, Time 17:41:11.604: Client name is BRUCE-DESKTOP

140 Opening GPSout port COM8, speed=4800 -- OK!

151 Attempting to connect now

151 Trying TCP/IP host "Aurora" port 8002 ...

151Okay, IP Address = 192.168.1.5

151 Connection made okay!

Here is the wideclient.ini file:

; PLEASE SEE WideFS documentation for parameter details

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

[Config]

Port=8002

Window=250,250,160,31

Visible=Min

ServerName=Aurora

UseTCPIP=Yes

ButtonScanInterval=20

ClassInstance=0

NetworkTiming=5,1

PollInterval=2000

ResponseTime=18

ApplicationDelay=0

TCPcoalesce=No

WaitForNewData=500

MaxSendQ=100

OnMaxSendQ=Log

NewSendScanTime=50

Priority=3,1,2

Log=DebugAll

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

[user]

Log=Errors+

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

[GPSOut]

Port=COM8

Speed=4800

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

Here is the wideserver log file:

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

Blocksize guide = 4096 (double allowed)

Date (dmy): 14/05/06, Time 15:11:02.953: Server name is AURORA

229000 Initialising TCP/IP server

229078 Initialising IPX/SPX server

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

229078 Failed to start IPX/SPX Server

230094 Broadcasting service every 1 mSecs

9008875 Incoming connection Accepted ok (skt=22540)

9008891 Connected to computer "BRUCE-DESKTOP" running WideClient version 6.510 (skt=22540)

9008891 Client capabilities: 04 (GPSout=Y) (skt=22540)

9039750 Error 10054: client socket disconnected at Client: removing (skt=22540)

9039750 Auto send stopped before sending all data (0 of 136 sent), Error=10038 (skt=-1)

Here is my wideclient.ini file:

; PLEASE SEE the documentation for parameter details

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

[Config]

Port=8002

AutoRestart=0

AutoUpdateTime=13

MaximumBlock=4096

NoStoppedRestarts=Yes

RestartTime=10

SendTimeout=15

TCPcoalesce=No

AdvertiseService=Yes

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

[user]

Log=Errors+

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

[ClientNames]

1=BRUCE-DESKTOP

Wideclient literally sucks up every available cpu cycle. I am unable to shut the program down by closing the window. I have to terminate the process from task manager.

Reading through previous posts, someone else mentioned this problem and found that some DLLs from another program were binding to wideclient and using up CPU cycles. I downloaded the Depends21_x86 program that analyzes what wideclient loads when it runs, but I don't know enough about wideclient to tell if anything extra is getting loaded. I tried to compare the depends21 log between a computer that is operating correctly and the computer with the problem, but that didn't help either.

I've disabled all firewalls, virus protection, and anything else that could be a factor in the network transfer.

Do you have any suggestions? Are there any other logs that I can provide to help diagnose the problem? Unfortunately, I can't tell you what programs were loaded onto the computer between the time wideclient was working and stopped working correctly. It's just so odd that something is making wideclient behave so erratically.

Thanks for any assistance you can provide.

Bruce

[Pete Dowson]

Opening task manager, wideclient was using 99% of the CPU and choking off the other apps. What is so puzzling is that this was a sudden change and wideclient worked so well before, hardly using 1% of the CPU, if that!

Ouch. Something obviously changed then! I really don't think that could happen with nothing changing.

Is this BEFORE any client applications (using WideClient) are running, or after? One reason you can get this is a client application stuck is a very tight loop calling WideClient. Other reasons are all tied up with the Network, as any loops in WideClient involve Network calls.

Here is the log from wideclient on the problem computer:

Which shows a good connection and nothing more.

Here is the wideclient.ini file:

In which you have "Log=DebugAll" in the wrong section -- it won't do anything there, so please delete it. Logging is controlled in the User section.

Do you have any suggestions? Are there any other logs that I can provide to help diagnose the problem?

Before we go into more logging, could you please try the latest WideFS (Server and Client) available above in the Interim Versions thread? A lot has changed and I cannot really deal easily now with 6.51 detailed logs -- I had planned to release 6.60 before now but other things keep getting in the way! ;-)

Let me know. If it is still the same, use Log=DebugAll, but in the correct section of the INI. The log will get large so don't run it longer than necessary to see the problem. You'd need to ZIP it up then and send it to me at petedowson@btconnect.com.

If it is a Network problem then I may not be able to help easily even then, but it is worth a look.

Regards,

Pete

[Bruce_N]

Is this BEFORE any client applications (using WideClient) are running, or after?

The 99% CPU load occurs after launching WideClient and before any client applications are running. It also only occurs once the connection to WideServer is established. Before the connection, taskman indicates 00% CPU.

Please try the latest WideFS (Server and Client) available

I downloaded and installed the latest Interim Versions. No change in the behaviour. Here is summary of the taskman activity:

Launch WideClient, taskman indicates 00% CPU

Launch FS, FS begins running, title bar indicates 1 connection

Taskman shows jump from 00% to 48% CPU on WideClient app

1 second later, CPU begins to climb to 60%-64% and hovers for a couple of seconds

After 3 seconds, CPU moves up to 96% and stays in the 94% to 96% range

After 10 seconds, CPU reaches 99% and stays there.

Only way to stop WideClient at this point is by terminating via taskman

I enabled full logging and will send the zipped log to your email box. I only ran the log for 5 seconds or so. I hope it gives an indication of the problem.

Thanks for your help,

Bruce

[Pete Dowson]

I downloaded and installed the latest Interim Versions. No change in the behaviour.

...

I enabled full logging and will send the zipped log to your email box. I only ran the log for 5 seconds or so. I hope it gives an indication of the problem.

Sorry, no, it doesn't. In fact the log shows everything behaving very well. This log actually shows entry times and exit times for message processing, and there are plenty of gaps between.

It is either a problem with the Network at some level before anything I can see in WideClient, or possibly a problem with something like button scanning. Are you programming any buttons from Client devices to the Server? Might you have something to do with EPIC of GoFlight present, or maybe some now unused but still installed joystick drivers? I seem to vaguely recall there was a problem with something like that a while back.

To test, set ButtonScanInterval=0 in the [config] part of the INI. That will turn all the joystick, EPIC and GoFlight checking off.

I see you also have a GPSout capability configured on this client. It looks to be operating, but that's another thing you could try eliminating, just as a test. Maybe there's something up with the serial port it is using.

Regards,

Pete

[Bruce_N]

I see you also have a GPSout capability configured on this client. It looks to be operating, but that's another thing you could try eliminating, just as a test. Maybe there's something up with the serial port it is using.

I have disabled the GPSOut as one of the first checks, but it has no affect. BTW, it was brilliant of you to add the GPS data via the network rather than a serial port. I can now monitor my flight's location from anywhere within my wireless realm via my laptop (even outside of the house). It was a major advancement!

Might you have something to do with EPIC of GoFlight present, or maybe some now unused but still installed joystick drivers? I seem to vaguely recall there was a problem with something like that a while back.

I think you may have discovered the problem. The WideClient PC has a game port adapter card and about the time this problem started is the time I removed my old joystick and put it in storage. FSUIPC is set up to assist with the fidelity of the joystick and throttle settings on the joystick.

I'm at work now, but when I return home, I'll disable the game port driver and see what happens. I'll go to the ButtonScanInterval=0 setting as a further test if disabling the driver does not fix the problem.

Regards,

Bruce

[Pete Dowson]

The WideClient PC has a game port adapter card and about the time this problem started is the time I removed my old joystick and put it in storage.

Ahif the system thinks there's a Game Port device there, but it is unplugged, it can't tell EXCEPT by awfully inefficient timeouts. That indeed does sound like the culprit. More modern game ports did these things asynchronously, but the old design (as invented in fact for the very first IBM PCs) was rather a kludge really, timing the discharge of a capacitor through the pot -- the worst case being of course a disconnected pot as when there's no joystick.

Regards,

Pete

[Bruce_N]

Eureka Pete!

I went into Device Manager, disabled the game port driver, and everything is back to normal.

Thanks for your help!

Bruce

[Pete Dowson]

Eureka Pete!

Great!

Good flying now! ;-)

Pete