Wideclient connection problem

[marcus.km]

Hi

I have the problem that Wideclient and Wideserver lost connection after X time.

I fly, lets say one hour with PM, then i get disconnected from wideclient/server.

See this:(status bar where the read and writes are counted)

http://www.marcus-schneider.com/Unbenannt.JPG

181 connected???? I have only one Wideclient.

here the 2 logs:

http://www.marcus-schneider.com/WideClient.log

http://www.marcus-schneider.com/WideServer.log

Using FS9.0

PM, GC, MCP,CDU, AS2004.5, IVAP, Teamspeak

Wideclient.exe/Wideserver.dll 6.4.4.0

Using TCP/IP in the wideclient and wideserver.configs

regards

Marcus

[Pete Dowson]

181 connected???? I have only one Wideclient.

I am off-line from now for a few days -- guests and relatives to attend to.

The phenomenon of multiple connections is fully explained in the documentation. Please take a look.

Sorry, but I don't ever have time to go browsing in assorted websites. If you want to show me something do so here, or ask where to send attachments. but please don't bother for at least 3-4 days. Your best bet at present is to check the documentation. It does encompass just about everything I know about Networks. After that you need Network expert help, or do as I do -- trial and error, replacing things, reinstalling things, and so on.

One thing is reasonably certain, you have a problem on a client PC.

Regards,

Pete

[marcus.km]

hm, at least i expected a small hint to a topic or at least manual page.....

but ok, well done...

[Hunziker]

Hi Marcus

Same problem...

I'm using now the old WideClient/WideServer 6.4.1 and the new FSUIPC 3.44.

No problem now...

Regards,

Steve (LSZH)

[marcus.km]

http://744.hoppie.nl/forum.cgi/frames/read/611

got it here.

going now to test it...

[marcus.km]

tested it with 6.4.1 no problems there, but now very big stutters with my IPX configs from wideclient :-((((

[jan737]

Hi Pete

Same problem over here after updating fsuipc 344 and widefs 644.

Never had trouble before.

It's amazing that several users have the same problem after updating and also have problems with there network adapter, cables and so on.

Couldn't find a solution in the widefs doc's to islolate the problem on the client.

Is there a solution or do you have a hint?

Attached the log file.

kind regards

Jan Geurtsen

[marcus.km]

i think it is just strange....with 6.4.1 no problems, but problems with 6.4.4. so our network adapters or cables are causing now problems but before?

I really guess its a Soft Problem.

Anyone is using IPX with 6.4.1?

I have big stutters with 6.4.1 but dont have big stutters with 6.4.4 (same configs)

[Pete Dowson]

i think it is just strange....with 6.4.1 no problems, but problems with 6.4.4. so our network adapters or cables are causing now problems but before?

I really guess its a Soft Problem.

Not necessarily. The main change, for generally better WideFS performance, was defaulting the old "Timeout" parameter in the WideClient.ini file to 0 in the new "ApplicationDelay" parameter. To get that back the way it was in 6.41 you need to set that new parameter to 6.

However, this should not be necessary -- certainly not on WinXP clients, unless it is with some badly behaved client programs.

Please, anyone with this problem, new with 6.44, please tell me just two things:

1. The windows operating system in the Client PC, and

2. The application programs being run in that PC.

If this parameter does look like the reason, perhaps I will have ot devise a way for it to automatically adjust upwads when unwanted reconnections occur.

Please also check the WideClient logs. Can you tell me roughly how frequently the reconnections occur (the numbers on the left are in milliseconds -- just divide by 1000 for seconds).

Thanks,

Pete

[marcus.km]

Hi Pete,

WideFS6.4.4. running on WinXP Home and XP Prof.

1 Client Machine running:

2x GC, 1 CDU, 1 MCP

second test was with:

1 GC 1 CDU

it appeared on both configs

In the moment i have only these two logs, cause since i am playing with 6.4.1 i dont had this problem, but with 6.4.1. i have really heavy sutters

http://www.marcus-schneider.com/WideServer.log

http://www.marcus-schneider.com/WideClient.log

if you still need further infos, lemme know

[Pete Dowson]

WideFS6.4.4. running on WinXP Home and XP Prof.

1 Client Machine running:

2x GC, 1 CDU, 1 MCP

second test was with:

1 GC 1 CDU

it appeared on both configs

But the one Client log you sent shows:

200 New Client Application: "pfd" (Id=2536)

200 New Client Application: "cdu" (Id=2784)

831 New Client Application: "pmSounds" (Id=2668)

3835 New Client Application: "AS2004" (Id=2032)

Did you forget pmSounds and AS2004? I think the latter is pretty heavy at times with its network access, and of course it is also using the Internet -- is that via the Network too?

The problem with stutters is likely due to (a) multiple PM GCs competing for WideFS access. You need "UseTimer=On" in the least important of the two. and (b) on the PC with one GC the stutters are more likely due to AS2004 activities.

The reconnection problem is due to this:

2275391 Send() request depth is over 100! Will re-connect:

You can stop it reconnecting on such errors (see documentation -- in particular please review the changes listed in the History section, at the end). However, that doesn't really solve the root problem -- the inability of the client to send messages to the Server is going to clobber things one way or another in any case. Please check your logs with 6.41. there may be similar things happening.

Unfortunately, neither Client nor Server logs were closed, so I see no performance information. Please close FS and clients first before showing logs.

So, what frame rate limit are you setting in FS2004? That could be crucial. It evidently isn't coping at present.

And do try setting ApplicationDelay=6 in the Client INI files. It most certainly shouldn't be needed for any of those applications, but you need to slow their demands down to alleviate the loads.

Regards,

Pete

[marcus.km]

Pete,

you are right, "those" old logs was my first tests with 6.4.4.

So there was some other clients and different loaded on the machines.

I just doing some tests here with 6.4.4. and the only thing i changed is MaxSendQ from 100 to 200 in this hard/soft config is:

1. FS

2. 2x GC, 1x MCP, 1x CDU ( 1xGC is PFD+ND and 1x GC is EICAS with usetimer=on)

3. ActivSky and IVAP Teamspeak

(No PMSounds so far)

Well, atm i have no problems since i am using MaxSendQ to 200 :-/

Dont know if that is a "clean" solution but it works ATM.

I look my Frames in FS at 25!

i will now continue my tests and if it appears again i will set the Option with ApplicationDelay=6

For your review i am using at the moment this Client settings on Client 2 and 3 (mostly default except MaxSendQ)

http://www.marcus-schneider.com/WideClient.ini

[Pete Dowson]

I just doing some tests here with 6.4.4. and the only thing i changed is MaxSendQ from 100 to 200

Okay, but performance is still being affected if the Queue is getting to 100. When you close the Client, the log will show the maximum size reached. On my 6 PC system the biggest I normally get is 10, but usually around 2, which is good. I even have 3 x GC on one of them (but nothing else on that one).

Well, atm i have no problems since i am using MaxSendQ to 200 :-/

Check the logs anyway. I'd like them compared between 6.41 and 6.44 to understand the differences, apart from this "reconnect" facility on high send queue sizes.

I look my Frames in FS at 25!

Okay. When you have everything running okay you can try changing that -- I have good performance now with unlimited frame rates in FS, but this is with IPX/SPX and it has only been possible because of all the recent WideFS improvements.

i will now continue my tests and if it appears again i will set the Option with ApplicationDelay=6

Okay. If the logs from 6.41 and 6.44 are signifcantly different, then this would be the most likely change which has caused it.

Regards

Pete

[marcus.km]

Pete,

i´ve finished my testflight with 6.4.4. now to show you the 3 logs.

Software Config is still as described in my last post:

http://www.marcus-schneider.com/WideClient_client2.log (strange here, only 1 GC joined....but here are 2 GCs running )

http://www.marcus-schneider.com/WideClient_client3.log (seems normal here)

http://www.marcus-schneider.com/WideServer_fs.log

the MaxUsed 24 is very high i guess :-//////

But at all, since i am using MaxSendQ=200, i got no Multiple Connections Problem.

But that have nothing to say, will make further testflights tomorrow.....

The Performance with 2 GCs with usetimer=on at EICAS GC is ok, not that best, but its ok.....

so far....

[Pete Dowson]

strange here, only 1 GC joined....but here are 2 GCs running

They won't both be identified as separate. They have the same name and joined one after the other -- Wideclient avoids repeating messages else some client apps would fill the log by contant re-Opening attempts.

the MaxUsed 24 is very high i guess :-//////

Well, that is not that high that you should worry unduly. But this is a puzzle ...

But at all, since i am using MaxSendQ=200, i got no Multiple Connections Problem.

.. because changing that limit from 100 to 200 would have absolutely no effect on reducing it from over 100 to only 24. It cannot, it is only a limit on the count. Something else has changed.

The Performance with 2 GCs with usetimer=on at EICAS GC is ok, not that best, but its ok.....

Yes, I agree. I have 3 x GCs, because I also have the FO's PFD/ND. But why don't you use the single copy GC with PFD/ND and EICAS, stretching the window over both monitors?

Regards

Pete

[marcus.km]

Yes, I agree. I have 3 x GCs, because I also have the FO's PFD/ND. But why don't you use the single copy GC with PFD/ND and EICAS, stretching the window over both monitors?

Regards

Pete

You got me, i dont know why.....never thought about this solution.....hmm

Will try that tomorrow.....

Lemme ask a question, why are you using 3 copies of GC instead of 2 or one, on the same machine? Just for my interessed....

[marcus.km]

Pete,

i trying now to use only one GC for PFD+ND and EICAS, but i am unable to resize the EICAS without re-sizing the PFD+ND.

The commands in the PM Docu doesnt help.

I am using GC 418 since 421 i am unable to resize the GC seperate from the Frame (it is a feature, but, well....not for me, cause the frames overlapping the GC :-(( )

[Pete Dowson]

i trying now to use only one GC for PFD+ND and EICAS, but i am unable to resize the EICAS without re-sizing the PFD+ND.

Hmmthat's a question for Enrico. Seems a bit strange not to be able to do that.

Anyway, on your original problem, the one with the continuous "Send Queue over 100" failures, I found a bug in WideClient which, if such an error occurs once, it can then keep recurring forever -- the timing of the reconnection was interfering with the timing of the send queue being cleared (these things are tricky, being in different threads now).

In other words, although you shouldn't have got a send queue as large as 100 in the first place, once you did get one so long, the bug in WideClient activated and made it much worse by not recovering.

I attach a revised WideClient.exe (version 6.441) to be used instead of 6.44 -- the only change is this fix.

I'll post this in the PM Newsgroup/Forum too.

Regards,

Pete

WideClient6441.zip

[marcus.km]

Hi Pete,

i just did a test flight again with !!6.4.4. and the flight was well done.

After landing i dont closed the Applications. I still let the Apps run.

After one hour or so, he starting counting

Find attached the logs.

http://www.marcus-schneider.com/WideServer_1.txt

http://www.marcus-schneider.com/WideClient_2.txt

http://www.marcus-schneider.com/WideClient_3.log

Great to hear that you found a bug.

I will test it now (with default configs) and will report back.

[Pete Dowson]

i just did a test flight again with !!6.4.4. and the flight was well done.

After landing i dont closed the Applications. I still let the Apps run.

After one hour or so, he starting counting

You are getting really bad blockages:

17368235 Send() request depth is over 200! Will re-connect

Over 200 !!!!

The fact that they take so long to start sounds rather like something has a memory leak somewhere, and clogging up things completely.

You don't say yet whether you tried the ApplicationDelay=6, nor have I seend any logs from 6.41 for comparison -- possibly you were getting enormous Send Queues in 6.41 as well. This has probably only just come to your notrice effectively because, with the bug in WideClient, it was no longer recovering. Otherwise they'd eventually cause bad stuttering and maybe poor response.

Great to hear that you found a bug.

I will test it now (with default configs) and will report back.

The bug was only that, once you get your huge send queue, it never recovers. The fix won't solve the problem which you have, which I would guess was also happening on 6.41. Something is certainly very wrong somewhere in your system. The log from your "MARCUS-OFFICE" PC was good and how it should be:

18237859 Max receive buffer = 584, Max send depth = 5

Something is wrong on the other Client, for sure. But whether it is a program or hardware or driver I'm afraid I have no idea. That's where I would start a process of elimination.

Regards,

Pete

[marcus.km]

You don't say yet whether you tried the ApplicationDelay=6, nor have I seend any logs from 6.41 for comparison -- possibly you were getting enormous Send Queues in 6.41 as well. This has probably only just come to your notrice effectively because, with the bug in WideClient, it was no longer recovering. Otherwise they'd eventually cause bad stuttering and maybe poor response.

Well, now i will test 6.4.4.1 and will add ApplicationDelay=6

Something is wrong on the other Client, for sure. But whether it is a program or hardware or driver I'm afraid I have no idea. That's where I would start a process of elimination.

I dont know it, too.

This client have a clean WinXP Home installation since 2 days with the lateast GeForce Drivers.

After the Installation i only installed GC, MCP, CDU, WideFS, DX9.0c WinSP2 and Geforce Driver!

Thats all.

[marcus.km]

did now a testflight for around 1 hour with your wideclient 6.4.4.1

All was fine.

Here the logs

http://www.marcus-schneider.com/logs/WideServer.log

http://www.marcus-schneider.com/logs/WideClient_2.txt

http://www.marcus-schneider.com/logs/WideClient_3.log

The used Ini file:

http://www.marcus-schneider.com/logs/WideClient.ini

I have to admit that i have some "mini" stutters now, dont know the cause.....but its not that really big, dont know if this is adjustable

I have to make longer flights to check if the Multiple Connection still occurs....

[Pete Dowson]

did now a testflight for around 1 hour with your wideclient 6.4.4.1

All was fine.

But that isn't because of the fix in 6.441. The two client logs show everything good:

PM:

4603156 Reception maximum achieved: 37 frames/sec, 7023 bytes/sec

4603156 Reception average achieved whilst connected: 32 frames/sec, 119 bytes/sec

4603156 Max receive buffer = 869, Max send depth = 3

and MARCUS-OFFICE:

4508250 Reception maximum achieved: 32 frames/sec, 1568 bytes/sec

4508250 Reception average achieved whilst connected: 10 frames/sec, 437 bytes/sec

4508250 Max receive buffer = 368, Max send depth = 2

So the only change which could have done this is your setting

ApplicationDelay=6.

Really, this is odd, as it should not be necessary to slow the programs down like this, at least not on Windows XP which is quite good at multi-tasking. It is as if you are using Win98 on that client.

I have to admit that i have some "mini" stutters now, dont know the cause.....but its not that really big, dont know if this is adjustable

It may simply be this Application delay. It makes every access by each of the programs take AT LEAST 6 milliseconds. Maybe you can try reducing it. Experiment with it both lower and higher.

The other thing you can try is increasing the new parameter "SendScanTime". This defaults to 10, limiting block send rates to 100 per second at most. You could try that a lot higher, say 50 (limiting to 20/sec). If that does no harm, leave it like that and reduce the ApplicationDelay again. Some balance of the two might help.

Sorry, I cannot be more specific. The changes between 6.41 and 6.44 were tested over a reasonable period, including many interim test releases on the PM forum/Newsgroup, and things looked like they were just about optimum. There's something rather different happening somewhere on your system, but why and where I really have no idea.

I have to make longer flights to check if the Multiple Connection still occurs....

The "multiple connection" thing isn't important -- that is merely a result of something else. Always look at the logs and "feel" the performance.

Summaries at the end like the two you have now are good -- a reasonable average frame rate and a low max Send Queue is what you want to see, and if you can smooth the stutters so much the better -- as I say, try adjustments in those two parameters, ApplicationDelay (as low as possible, preferably 0), and SendScanTime (10-100 is a reasonable maximum range to try within).

Regards,

Pete