Jump to content
The simFlight Network Forums

about wideclient.txt for Mr. Dowson.


Recommended Posts

Hello Pete and all the rest,

Could anyone tell me hot to fix this?:

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

Date (dmy): 06/11/03, Time 16:17:36.625: Client name is COMPUTER2

140 Attempting to connect now

156 Connection made okay!

[...]

695531 send() done [27 bytes] after 13 retries, request depth is 44

1341375 send() done [27 bytes] after 12 retries, request depth is 70

1595375 send() done [27 bytes] after 8 retries, request depth is 41

2074875 GetRecv() missed block? Sequence 76093 jumped to 76095

2170797 Note: Send() request depth is over 100!

2315156 send() failed [0 bytes] after 40 retries, request depth is 1717

2315156 Ready to try connection again

2315172 Attempting to connect now

2315172 Connection made okay!

2328281 Note: Send() request depth is over 100!

2365625 send() done [133 bytes] after 19 retries, request depth is 1059

2380640 send() done [149 bytes] after 7 retries, request depth is 1473

2404453 Note: Send() request depth is over 100!

2474687 send() done [25 bytes] after 14 retries, request depth is 54

2478781 send() done [25 bytes] after 11 retries, request depth is 164

2573219 send() done [85 bytes] after 9 retries, request depth is 51

2887437 send() done [27 bytes] after 10 retries, request depth is 51

2986828 send() done [85 bytes] after 36 retries, request depth is 158

3022969 send() done [149 bytes] after 15 retries, request depth is 84

3113312 GetRecv() missed block? Sequence 40650 jumped to 40652

3114062 GetRecv() missed block? Sequence 40678 jumped to 40680

3153062 GetRecv() missed block? Sequence 42635 jumped to 42637

4306172 Note: Send() request depth is over 100!

25599422 Reception maximum achieved: 64 frames/sec, 13453 bytes/sec

25599422 Reception average achieved whilst connected: 17 frames/sec, 25 bytes/sec

25599422 Max receive buffer = 5248, Max send depth = 1716

25599422 ********* Log file closed (Buffers: MaxUsed 1675, Alloc 847675 Freed 847676 Refused 0) *********

I don't think this log file is very normal. I'm using FS2004

Link to comment
Share on other sites

Could anyone tell me hot to fix this?

...

I don't think this log file is very normal. I'm using FS2004

It is possibly a performance problem. It looks like the Server is not responding fast enough so messages from clients are piling up. How many clients do you have? What is the processor where FS + WideServer is running? What is your FS frame rate limiter set to? What is the Network - 10 or 100 Mbps, and is it via a hub or switch?

A look at the WideServer.log may help too.

Anyways, try, as an experiment, severely reducing your FS frame rate limit. If this helps, then the problem is that WideServer is not getting enough FS PC time to meet all the demans from the clients whilst also trying to send stuff out at FS's frame rates. You may find a "sweet spot" that suits your set up.

There are some parameters to limit the Server actions so it doesn't send so much out, but in general it is better to achieve a balance without using those.

Regards,

Pete

Link to comment
Share on other sites

Ok Pete,

When this happened I had two clients running. Wide Server is running on FS2004 on a Pentium IV at 2.4 Ghz with 512 Mb of DDR RAM. The client I got that file from is a P-IV @ 1.7 Ghz with 256 Mb of RAM. All clients use 100Mb Network Cards connected to a switch.

At the time this file was logged, FS2004 had the framerate set to unlimited. I'll try limiting the frames to, let's say, 35 to see what happens.

Here is the wideserver.txt, altough it's from a later session than the previous wideclient.txt that I sent you (I didn't save it):

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

Using blocksize guide of 2048 bytes

Date (dmy): 10/11/03, Time 11:27:50.581: Server name is SIMULADOR

93031 Initialising server socket now

100984 Incoming connection Accepted ok (skt=2856)

101062 Connected to computer "COMPUTER2" (skt=2856)

146390 Incoming connection Accepted ok (skt=2904)

146468 Connected to computer "COMPUTER3" (skt=2904)

492000 Client socket disconnected at Client: removing (skt=2856)

544828 Incoming connection Accepted ok (skt=4340)

544906 Connected to computer "COMPUTER2" (skt=4340)

562109 Client socket disconnected at Client: removing (skt=4340)

567359 Closing down now ...

Memory managed: Offset records: 332 alloc, 332 free

Throughput maximum achieved: 94 frames/sec, 16202 bytes/sec

Throughput average achieved for complete session: 18 frames/sec, 2231 bytes/sec

********* Log file closed *********

Pete, thanks for your prompt reply to the subject.

Link to comment
Share on other sites

When this happened I had two clients running. Wide Server is running on FS2004 on a Pentium IV at 2.4 Ghz with 512 Mb of DDR RAM. The client I got that file from is a P-IV @ 1.7 Ghz with 256 Mb of RAM. All clients use 100Mb Network Cards connected to a switch.

At the time this file was logged, FS2004 had the framerate set to unlimited. I'll try limiting the frames to, let's say, 35 to see what happens.

Okay. Two things about this.

First, 512Kb was great for FS2002 but I think you'll find better performance with more memory -- and at present it is a pretty cheap upgrade, so well worthwhile. However, this depends on your Operating System, which you don't mention. You'd need Windows XP (or 2000). I think the "sweet spot" for FS alone is about 768Mb, but you are better off with 1Gb with other things (like WideServer, FSUIPC) running too.

Second, I found WideFs ran best in FS2004 on my 2.4 Gb Pentium 4 with the frame rate limiter set at 25 or even 20. In fact I've now upgraded to a 3.2 Pentium and still have the limiter set to 20! This way I can have everything turned up max in FS and feed 4 WideClients smoothly at 20 fps too. FS stays at 19.9 fps most all the time (on my 2.4 GHz it dipped well below that now and then if I dared have all the settings to max).

In other words, unless you have graphics and AI turned down I think 35 fps is still too high. But by all means experiment, see what you find.

Your Server LOG shows no Netwrok problems, which makes me even more convinced it is just a performance bottleneck problem.

Regards,

Pete

Link to comment
Share on other sites

Hello Pete,

Well, we're using Windows XP Pro in both the machines the files came from. TCP as the protocol.

I don't have detail set to max in FS, since for me, FPS is more important than pretty scenery. I use 800*600 in 16 bpp so that I can get decent FPS. I will be changing he graphics card to a newer one, though. So, my FS2004 FPS wasn''t the problem (I get 35). Something else is happening. 20 fps is too low for me.

About RAM size, you might be right. We'll try increasing the amount of RAM to see what happens.

Do you think this could be a TCP issue? When I started testing with your software and with Project Magenta Demos, I found out that IPX worked out better (smoother movement graphics). Now I've got it using TCP. Smoothness is a key target in our project to build a home simulator.

Here's the wideserver ini

; PLEASE SEE the documentation for parameter details

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

[Config]

Port=8002

AutoUpdateTime=10

RestartTime=0

MaximumBlock=2048

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

[user]

Log=Errors+

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

And here is the Wide Client Ini

; PLEASE SEE WideFS documentation for parameter details

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

[Config]

Port=8002

UseTCPIP=yes

ServerIPAddr=192.168.0.9

Timeout=0

Window=32000,32000,160,34

Visible=Yes

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

[user]

Log=Errors+

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

I hope this helps.

Link to comment
Share on other sites

So, my FS2004 FPS wasn''t the problem (I get 35). Something else is happening. 20 fps is too low for me.

Do you mean to say you didn't even bother to try reducing it to see if that was the problem?

Why is 20 fps too slow? Surely 20 fps all the time, on your FS PC and your clients, nice and smooth, is far better than 35 fps sometimes dipping and with clients stuttering like crazy?

I find 20 fps very smooth on FS2004. What's the problem with it?

If you aren't even willing to try it, to see if the problems you are having are merely performance, why ask me to help? :(

If it is okay at 20, raise it to 25, if okay at 25, raise it to 30. find the "sweet spot".

Do you think this could be a TCP issue? When I started testing with your software and with Project Magenta Demos, I found out that IPX worked out better (smoother movement graphics). Now I've got it using TCP. Smoothness is a key target in our project to build a home simulator.

IPX (actually it is SPX it uses) is a lot simpler in terms of implementation. There are a lot less levels involved, so it is more efficient. I've always preferred it. However, there is no doubt that is can be a pain with Windows NT/2K/XP. However, there are folks using it, so you could try.

TCP/IP has the advantage that users will generally have it installed already, and it is less of a problem to set up on systems with any of WinNT/2K/XP involved. It is also the only one really being developed and supported by Microaoft in any case, so it gets better with each windows release (at least it is a lot better in XP than it was in NT).

Most of the improvements I've made (and they are mostly timing changes, not fundamental things) in the last year or so have been aimed at getting WideFs running smoothly using TCP/IP. I think this has been achieved.

The main change this year has been between FS2002 and FS2004. the demands on the processor from FS2004 are much greater. This leads to a greater need for WideFs to be set up well and given enough time.

Here's the wideserver ini

Please use the default values. Most of them took many weeks of testing and adjusting to get "just so". At least delete your "AutoUpdateTime" and "MaximumBlock" parameters. Why did you change them?

And here is the Wide Client Ini

Again, apart from adding your Server's name or IP address, please let the parameters default. Delete the "Timeout=0" line, that could certainly make a mess of the timings.

I spent a lot of time trying to get the best, smoothest, performance on the majority of systems, and the defaults are set for that. ALWAYS use default values first, only adjust any when you find you need to, or under advice.

Regards,

Pete

Link to comment
Share on other sites

Hi Pete:

>Do you mean to say you didn't even bother to try reducing it to see if >that was the problem?

Of course not. I tried, and the problem goes away at 15-20 fps on one client, but not on the other (slower computer). On the other hand, 20 fps is too little for me. I need at least 25. That's why I don't mind reducing detail levels or buying more RAM to try to fix it.

>Why is 20 fps too slow? Surely 20 fps all the time, on your FS PC and >your clients, nice and smooth, is far better than 35 fps sometimes >dipping and with clients stuttering like crazy?

>

>I find 20 fps very smooth on FS2004. What's the problem with it?

20 is just not enough. Make it 25 and my eyes stop seeing "flicker", and the movement is continous.

>If you aren't even willing to try it, to see if the problems you are having >are merely performance, why ask me to help?

Of course I am willing to try. I am sorry if I disturbed you with my question (not my intention at all), but It was just a lack of information supplied by me, since I didn't explain all the tests I made before coming to this forum to write down a problem. Again, sorry. :-(

About the ini files, I changed those settings trying to make the thing work, since someone sent me his ini files a while ago with these settings saying it worked for him. I noticed they didn't on my setup. I've always used defaults on everything unless I experience problems.

I'll let you know what happens tomorrow when I buy more RAM and a new Video Card.

One more question:

Assuming that with the new Video Card and RAM, FS2004 can achieve 35 fps at full quality, am I not gonna be able to use this rate without causing data loss to the clients?

Thanks,

Rafa.

Link to comment
Share on other sites

the problem goes away at 15-20 fps on one client, but not on the other (slower computer).

It should have nothing whatsoever to do with the speed of the client. your client logs showed blocking on sends, which means the client is working fast enough to send that many messages to the Server that it isn't keeping up.

If setting the Limiter to 20 doesn't fix this, you have certainly got something strange going on. Something is holding up messages leaving your client.

About the ini files, I changed those settings trying to make the thing work, since someone sent me his ini files a while ago with these settings saying it worked for him. I noticed they didn't on my setup. I've always used defaults on everything unless I experience problems.

In that case I am lost. i have no idea why your Server is not processing the incoming messages fast enough. It makes no sense. And how come you have two clients sending lots of messages TO the server in any case? Normally only control programs like Project Magentas MCP would be sending so many. What else it sending things? Most receive only. In fact WideServer is optimised to do a LOT more sending than receiving!

Assuming that with the new Video Card and RAM, FS2004 can achieve 35 fps at full quality, am I not gonna be able to use this rate without causing data loss to the clients?

Your log showed only a little data loss to the clients anyway, quite minor. It seems to be mainly the reverse problem you have, data being sent to the Server being blocked. What aps have you got sending data to the Server?

BTW I still think 35 fps is too fast for this. :o

Regards,

Pete

Link to comment
Share on other sites

Hello Pete,

I am working with the Project Magenta Sample programs to try to make this whole thing work before deciding about spending a large amount. Since These are time-limited, and location limited, I am unable to leave the computer running all night to see if things get worse.

On One Client I've got running the CGDemo and MCPDemo

On the other client the GCDemo (EICAS page) and CDUDemo.

On the main computer I have PMSounds too.

If I lower the FPS to 20, one client doesn't get the errors in the wideclient.log, but the other one does (the one with the CDU).

I'm gonna continue trying different setups to see if I get it to work. I'll let you know what happens once I increae the RAM and the Video Card (couldn't do it today).

Regards,

Rafa.

Link to comment
Share on other sites

On One Client I've got running the CGDemo and MCPDemo

On the other client the GCDemo (EICAS page) and CDUDemo.

... If I lower the FPS to 20, one client doesn't get the errors in the wideclient.log, but the other one does (the one with the CDU).

That's rather odd. The CDU shouldn't be trying to send all that much, certainly not as much as the MCP. Are the errors still on Send mostly?

Do you need to use the MCP graphic itself? If not then try that on the FS PC with the graphic minimised. That works well for me. Otherwise I think it is better on the same PC as the CDU as there is likely to be a lot of interaction between them.

Put CDU, MCP and EICAS on your fastest Client, PFD/ND on the other.

Did you check the GC/EICAS graphics frame rates? (Press F). Make sure it is using hardware acceleration for OpenGL.

You may get more advice about PM arrangements on the PM Newsgroup. Most of the experts hang out there and many folks have been working al this stuff out for years!

Regards,

Pete

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.