Connection issue ?

[eudoniga]

Dear Peter,

this time I started requesting help from the PM staff, but after they looked at the logs file produced by their modules, the answer was about a "connection issue" where I should check the wideclient.logs instead.

So here I am, and here they are.

I cannot tell exactly what happened to the small, happy LAN where the server IUIE has 4 clients (NICO, REMUS, JENNY & GAIA), two of which started to "suffer" ...

- NICO runs a PM Glass Cockpit module that cannot find his mates anymore,it doesn't find the CDU and MCP running on JENNY, the NetDir folder (ibidem) and the main FlightSim folder (on IUIE), all of which have been shared properly.

- GAIA runs the program Airport Chart Viewer by Manuel Ambulo, which - after a few minutes from connection - declares itself unable to get more data from FSUIPC...

I had a look at all the logs, all of which are reporting problems.

All PCs used to work properly, and now NICO & GAIA don't behave as expected; alas, I cannot see what I may have done to spoil the previous situation, where everything worked :cry:

Can you help me ?

Thanks a lot and regards,

Eugenio Remus.

WideFSlogs.zip

[Pete Dowson]

I cannot tell exactly what happened to the small, happy LAN where the server IUIE has 4 clients (NICO, REMUS, JENNY & GAIA), two of which started to "suffer"

...

- NICO runs a PM Glass Cockpit module that cannot find his mates anymore,it doesn't find the CDU and MCP running on JENNY, the NetDir folder (ibidem) and the main FlightSim folder (on IUIE), all of which have been shared properly.

I'm afraid this is not a WideFS "connection issue". The links those programs make to NetDir and the FlightSim folder are direct, via normal Windows file sharing, not via WideFS. WideFS only provides the link to FSUIPC, which appears to be working fine.

I don't think any PM glass cockpit goes looking for a CDU or MCP. The links are the other way I think. But that's all PM stuff which you'd need to discuss with them.

- GAIA runs the program Airport Chart Viewer by Manuel Ambulo, which - after a few minutes from connection - declares itself unable to get more data from FSUIPC...

A "few minutes"? The log shows the Airport Chart viewer starting up at time 296065 (296 seconfs after WideClient was started on that PC), and there are no problems until time 7440809, which actually looks about when FS or something was closed judging by all the other logs.

7440809 - 296065 = 119 minutes, or nearly two hours or incidentless connection! Then there was a loss of connection for about 38 seconds (maybe you were reloading something in FS or using its menus?) after which it carried on for another 2605 seconds (43 minutes) with no troubles. The errors after that seem to be the same as on all the others.

Furthermore, as the figures at the bottom show, it enjoyed a reasonable connection, probably commensurate with its demands:

8140365 Reception maximum: 25 frames/sec, 1075 bytes/sec

8140365 Reception average whilst connected: 10 frames/sec, 408 bytes/sec

8140365 Transmission maximum: 8 frames/sec, 595 bytes/sec

It made 3,210 requests over the two hours 42 minutes.

I had a look at all the logs, all of which are reporting problems.

The one for JENNY seems to be for a completely different session -- the time doesn't match at all. There are no errors except at the end, and the program hasn't been closed when you zipped the file.

REMUS started a little after GAIA and its "troubles" also occurred about 2 hours later, with pmSounds and pmRJ running without incident for that time. The sequence after two hours is the same as for GAIA, so it is probably activity on the Server interfering with the connection.

Exactly the same applies to NICO, with pmRJ again running okay for two hours or so.

Looking at the Server log (which, by the way, is also not terminated -- you do need to close FS so that the performance is logged), there are a couple of isolated NASTY errors:

76594 **** ERROR! Sumcheck or length fails on received socket 2876 block, len=1000 (time=0)

850015 **** ERROR! Sumcheck or length fails on received socket 2864 block, len=43 (time=0)

The first was on a block from GAIA, the second from NICO. Neither would do any lasting harm, but these sort of errors should NEVER occur. They mean data is occasionally getting corrupted. I've no idea how that can happen -- it'll be more likely hardware than software -- cables, hubs/switches/NICs. Possibly sharing an IRQ would do it too.

However, neither of these would have done anything noticeable. They are one-off errors and very very infrequent at that.

Apart from that, the disconnections and reconnections happen at the same time as they are reported in the Clients -- i.e. after the two hours of good running. They could be due to almost anything in FS other than flight or slew modes (lengthy times in menus, delays or long stutters loading scenery, aircraft, etc. These are quite normal and recovery is quick afterwards. The whole period of such errors is a bit long though).

If you were not doing things in FS when this period of problems started after the 2 hours of good flight, then I'm wondering if it is due to a memory leak problem. There are quite a few of these in FS, some fixed by the FS9.1 update. There are add-on sceneries (autogen I think) which can do it, especially if installed incorrectly it seems. If you are using FS with many add-ons it might be a good idea to search the various forums for help with this sort of thing.

Regards,

Pete

[eudoniga]

From what I see within the pfd.log of the Glass Cockpit running on client NICO, which I enclose, it DID try to look for the CDU, but did not find it ...

then you'll see a long chain of "read error" and I guess this is what made Katy and Enrico speak about a communication problem.

ACV: well, if the wideclient.log does show everything normal, I'm happy for it, but the program actually ceased to display the aircraft current position on the airport map, after displaying the message I quoted ...

Hardware: yes, whilst I don't remember changing any particular software setting, I recently moved the PCs from one table to another; they were probably (re)connected to different plugs of the same hub, using different cablesmaybe this is a good direction for further enquiries.

I'll let you know.

Thanks and regards,

Eugenio.

pfd.log (nico).zip

[Pete Dowson]

From what I see within the pfd.log of the Glass Cockpit running on client NICO, which I enclose, it DID try to look for the CDU, but did not find it ...

then you'll see a long chain of "read error" and I guess this is what made Katy and Enrico speak about a communication problem.

I don't know PFD logging. The PM support team would have to advise about what sort of Read Errors they are -- the sound like file access, which is not via WideFs. I also did not know the PFD actively "looked" for a CDU. Probably it looks for the NetDir in order to see if there are V-speeds and a route to display?

ACV: well, if the wideclient.log does show everything normal, I'm happy for it, but the program actually ceased to display the aircraft current position on the airport map, after displaying the message I quoted ...

Well, there's certainly no trouble with WideFS for the first two hours or so. I'm afraid I cannot say what happened to the program itself.

Regards,

Pete

[eudoniga]

Well, Peter, it is sure that strange things are happening.

Above all, I must consider that only a few days ago the whole system worked OK ...

That's why - after you pointed it out - I started to think to hardware problems, maybe an old ethernet cable,so I bought a brand new cable for the client NICO, tried different plugs of the hub, butnothing, the "blindness" persists ...

Strange enough, Wideclient is able to run and close applications on that pc, it does that with the PM module itself (remember those questions I made to you a few days ago, that's when the whole thing worked ...)

During the last flights I kept the GC running though if it couldn't display any "active" data, since it could not see the other modules. I have noticed that some time - abnormally - Wideclient locks up, even after closing the Glass Cockpit, so that I must use Ctrl-Alt-Del to shut it down and then switch the pc off ...

Another impression I got from comparing the two clients is that of a delayed feedback: when I start both GCs from the server (via KeySend), the one on the other clients starts immediately, while the one on NICO starts only after a few secondsand that's not just because it is a slower pc !

In general, though, the network file system functions seem to work ok: I can use Windows' Explorer from the server, or from other clients, to open folders, copy, delete and rename files, etc. ; NICO by itself sees the shared "NetDir" folder among the other network resourcesincluding the shared main FS folder ...

but the GC program running on NICO just can't find those folders !!!

As I have sent more materials to the PM staff to examine, don't know what else to think ...

Have a nice weekend and thanks SO MUCH for trying to be of help !!!

Regards,

Eugenio.

[Pete Dowson]

Well, Peter, it is sure that strange things are happening.

Don't forget that much of PM communication is via "NetDir". I assume you've run the PM checking program -- does that give everything a clean bill of health?

Above all, I must consider that only a few days ago the whole system worked OK ...

It did? So, what has changed. Have you installed anything, removed anything? If you've changed nothing, and you are sure you have not acquired any viruses or worms, then the problem may well be hardware -- software doesn't "develop" faults, they are either there or they are not. However, the possiblilty of file corruption, somehow, does arise -- reinstallation is then usually needed (more below ...)

... nothing, the "blindness" persists ...

Again this reference to "blindness". It sounds like the Netdir access for PM, not WideFs. Run the check program again. Your best bet for help with this is Katy Pluta of PM support. She helps me when I have Network Problems.

I have noticed that some time - abnormally - Wideclient locks up, even after closing the Glass Cockpit, so that I must use Ctrl-Alt-Del to shut it down and then switch the pc off ...

Are you sure the when this happens the Glass Cockpit is actually really fully closed? Just because the window disappears doesn't mean it has gone -- check with the task manager (Ctrl-Alt-Del), look in the Process list. All the cases I know of with WideClient locking have actually been due to the application locking.

If the PM process has gone completely, then the hang will be in the Windows networking routines or in the network driver. Try re-installing the network card -- in the Windows hardware manager uninstall it and reinstall it. If necessary, and it is a plug in (PCI) network card, actually deinstall it completely and re-install it.

BTW, you aren't using "pmGetWeather" are you? I find this occasionally locks -- it takes 99% of the CPU when it does so and everything else on that PC grinds to a halt.

Anyway, back to corruption: earlier this week something somehow corrupted something in my system. Upon booting up I was getting six or more consecutive crashes reported in "SVCHost", Windows Explorer took two minutes or so to open "My Computer" (every time!), and the whole PC reset itself now and then. I was going crazy. Katy suspected a worm or virus, but nothing was detected. Eventually, via the Event Log I found that the initial crashes were when Windows tried to start a service -- something about Image Acquisition. I found the service and disabled it -- and everything has been okay since! I suppose I still have a corrupt part of Windows, but, since it is a part I don't use, it now doesn't affect me.

I expect that if I wanted to use this disabled service I would need to re-install Windows completely. Maybe this is what you will need to do?

Regards

Pete

[eudoniga]

As usual, thanks for keeping on enquiring and sharing part of the load ...

Nope, I don't use PMGetWeather at all ...

Yep, the latest PMChecker version was run friday evening, it wasn't able to detect the NetDir, it wasn't able to see the CDU/MCP running, it wasn't able to find the FS2002 folder ...

And its suggestion were irrelevant:

- set limited frame rate in FS (already done, set to 25 FPS);

- run CDU/MCP (they were both running, and the other clients could see them);

- share the folders with appropriate names (already done, you could see them through Explore from that same machine ...)

So I tried to see what happened by asking WideClient to work on that same pc for another kind of application: FLightDeck Companion (which I normally run on the server).

Well, WideCLient started, and it allowed to be shut down soon after it was started.

When I tried to run the application, three things happened:

a) FDC couldn't go beyond the splash screen, so it couldn't even get to the first program window, and shut down.

b) WideCLient started to absorb some 98 % of the CPU;

c) WideCLient couldn't be shut down normally, so I had to use Ctrl-Alt-Del ...

After the network cable was found OK, I agree with you that I must move the "action" to a deeper level, that's the networking device and/or the operating system itself.

I will try to reinstall the network card first ...

Thanks and regards !

Eugenio.

[Pete Dowson]

Yep, the latest PMChecker version was run friday evening, it wasn't able to detect the NetDir, it wasn't able to see the CDU/MCP running, it wasn't able to find the FS2002 folder ...

Ah .. you certainly do have a Networking problem, then. Sorry, in your shoes I would be trying things one at a time, with the most difficult (e.g. re-installing Windows and everything else) last. You need to undertake a process of elimination.

I will try to reinstall the network card first ...

Okay, good luck! Please keep us informed. It may help others.

Regards,

Pete

[eudoniga]

Dear Peter, with Windows' reinstallation surely being the last thing on my mind, I am trying to understand what may be the cause for this situation, where only some of the clients don't behave ...

I have reviewed all of Enrico's hints about networking (the ones you find in the PM NOTAMs), and made sure I had followed them on all clients.

As for client Nico, I will try to reinstall the network adapterwill tell you later.

As for the pc that I borrowed from my office, named client "Mauro", which is BTW a 'twin' pc of other two clients, "Remus" and "Jenny" (which are both working okay), I noticed that though the situation isn't so tragic (there is no such "blindness"), the PM Glass Cockpit has greatly delayed feedback: everything that happens inside FS (parking brake on/off, cabin signs on/off, engine startup/shutdown) is shown on the GC with SEVERAL seconds of delay.

Would it help if I post you the Wideclient log for this other pc ?

The situation is slowly getting to my nerves ...

Thanks and regards,

Eugenio.

[Pete Dowson]

the PM Glass Cockpit has greatly delayed feedback: everything that happens inside FS (parking brake on/off, cabin signs on/off, engine startup/shutdown) is shown on the GC with SEVERAL seconds of delay.

WideFS isn't capable of queuing requests at either end. That symptom seems to always be a problem on the client where Windows is too busy doing something else to be bothered with incoming stuff on the Network, and the latter piles up in Winsock buffers. I think the last time it was reported it turned out to be video drivers, they were taking most of the processor time. Possibly the OpenGL drivers aren't up to scratch on that PC.

But it could be down to other processes. Check whatever else is running.

Also, for all PCs, check that the Network adapters aren't using an IRQ shared with anything else, and especially not the video card. This isn't supposed to matter so much with WinXP, but I've always found it much much better to keep the Network IRQ separate if possible (and it is essential on Win98/Me).

Would it help if I post you the Wideclient log for this other pc ?

I'll look at it, but it is unlikely to help. Your previous logs show no errors relating to your problems.

The situation is slowly getting to my nerves ...

It would mine. Some of the most frustrating periods in my PC life have been down to Network problems. I've thrown three network adapters and two hubs away in disgust in the last three years. Once I get things working I try to make no Network changes for fear of what may ensue. I have no Network experts to hand and have to rely, like you, on trial-and-error. And, yes, I've had to start from scratch on occasions and re-install everything from Windows up.

It may be time for you to bite the bullet soon I fear.

Regards,

Pete