Jump to content
The simFlight Network Forums

stutters


Recommended Posts

peter,

I'm getting bad stutters lately with PM software using WideFS. My client log has the following:

529738 WRITESTATEDATA received with bad data size!

529738 507 ReadLocal: Offset=0002, Size=0C27

548086 471 ReadLocal: Offset=0002, Size=5010

694035 512 ReadLocal: Offset=0002, Size=0168

1024470 Reception maximum achieved: 39 frames/sec, 4830 bytes/sec

1024470 Reception average achieved whilst connected: 19 frames/sec, 2662 bytes/sec

1024470 Max receive buffer = 1609, Max send depth = 3

1024470 ********* Log file closed (Buffers: MaxUsed 4, Alloc 59246 Freed 59246 Refused 0) *********

Anything to be worried about? Thanks

David

Link to comment
Share on other sites

I'm getting bad stutters lately with PM software using WideFS.

It's more likely to do with video drivers or some such than WideFs, which has not substantially changed for a long time. If by "lately" you mean it was okay once, you really need to track back and work out what you changed.

My client log has the following:

529738 WRITESTATEDATA received with bad data size!

529738 507 ReadLocal: Offset=0002, Size=0C27

548086 471 ReadLocal: Offset=0002, Size=5010

694035 512 ReadLocal: Offset=0002, Size=0168

The bad data size error is an error from a client program. But one such error will not produce stutters, it is merely a symptom of something wrong in that program. Maybe that is related to your stutters, I cannot tell. You need to ask whoever it is supports the program in question.

The ReadLocal lines don't make sense -- looks like things have shifted so the offset has become the size and vice versa. Weird. But if there are commands being sent with 'bad data', then maybe this can happen, so it may all be part of the same symptom.

BTW the "ReadLocal" lines should NOT actually be in the log if you are using the standard default settings! If you have changed the Logging to include such data the log file will get huge and certainly not help performance! Set the Log line to "Errors+".

Regards,

Pete

Link to comment
Share on other sites

Hi Peter,

Well, I have tracked down the source of my stutters. I did clean out some video driver problems but what seems to be the culprit is GFRemote (I use a GFMCP). This has worked fine in the past but now creates stutters of 1-3 seconds at 8-10 second intervals. I looked at the WideFS client log and have the following. Incidentally, I do have the error capture set up like you've suggested but continue to get these messages. I don't know if any recent changes in the MCP have created this or what. Thanks for any advice you might have! David

Date (dmy): 24/07/04, Time 23:13:20.220: Client name is AIDAN

21 Attempting to connect now

196 Trying TCP/IP host "Delxp" ...

196Okay, IP Address = xxxxxx (I omitted my IP address for the post)

206 Connection made okay!

14054 New Client Application: "PMRJ" (Id=-244145)

14490 WRITESTATEDATA received with bad data size!

14490 119 ReadLocal: Offset=68000000, Size=0149

436112 New Client Application: "MCP" (Id=-141609)

492260 New Client Application: "GFPMREMOTE" (Id=-161405)

502350 New Client Application: "GFREMOTE" (Id=-223945)

2033323 READSTATEDATA received with bad data size!

2033323 851 ReadLocal: Offset=786C6564, Size=5C70

2236825 4070 ReadLocal: Offset=786C6564, Size=5C70

3528071 WRITESTATEDATA received with bad data size!

3528071 499 ReadLocal: Offset=0002, Size=5010

4170294 READSTATEDATA received with bad data size!

4170294 0 ReadLocal: Offset=786C6564, Size=5C70

7595307 1045 ReadLocal: Offset=786C6564, Size=5C70

10428083 0 ReadLocal: Offset=786C6564, Size=5C70

10510366 1540 ReadLocal: Offset=786C6564, Size=5C70

17860069 117 ReadLocal: Offset=786C6564, Size=5C70

24915194 1047 ReadLocal: Offset=786C6564, Size=5C70

29075284 0 ReadLocal: Offset=786C6564, Size=5C70

29146353 send() done [27 bytes] after 6 retries, request depth is 15

30230118 READSTATEDATA received with bad data size!

30230118 0 ReadLocal: Offset=786C6564, Size=5C70

32465116 0 ReadLocal: Offset=786C6564, Size=5C70

37429865 GetRecv() missed block? Sequence 1389773 jumped to 1389787

37606281 GetRecv() missed block? Sequence 1401128 jumped to 1401142

37607757 GetRecv() missed block? Sequence 1401203 jumped to 1401216

37608697 GetRecv() missed block? Sequence 1401284 jumped to 1401296

Link to comment
Share on other sites

what seems to be the culprit is GFRemote (I use a GFMCP). This has worked fine in the past but now creates stutters of 1-3 seconds at 8-10 second intervals.

How odd. What's changed?

I looked at the WideFS client log and have the following. Incidentally, I do have the error capture set up like you've suggested but continue to get these messages.

Now you show a fuller log it is obvious that those lines are shown precisely because they are in error.

492260 New Client Application: "GFPMREMOTE" (Id=-161405)

502350 New Client Application: "GFREMOTE" (Id=-223945)

You have two GF remote packages running. Won't they clash?

2033323 READSTATEDATA received with bad data size!

2033323 851 ReadLocal: Offset=786C6564, Size=5C70

2236825 4070 ReadLocal: Offset=786C6564, Size=5C70

3528071 WRITESTATEDATA received with bad data size!

3528071 499 ReadLocal: Offset=0002, Size=5010

4170294 READSTATEDATA received with bad data size!

4170294 0 ReadLocal: Offset=786C6564, Size=5C70

7595307 1045 ReadLocal: Offset=786C6564, Size=5C70

10428083 0 ReadLocal: Offset=786C6564, Size=5C70

10510366 1540 ReadLocal: Offset=786C6564, Size=5C70

17860069 117 ReadLocal: Offset=786C6564, Size=5C70

24915194 1047 ReadLocal: Offset=786C6564, Size=5C70

29075284 0 ReadLocal: Offset=786C6564, Size=5C70

29146353 send() done [27 bytes] after 6 retries, request depth is 15

30230118 READSTATEDATA received with bad data size!

30230118 0 ReadLocal: Offset=786C6564, Size=5C70

32465116 0 ReadLocal: Offset=786C6564, Size=5C70

37429865 GetRecv() missed block? Sequence 1389773 jumped to 1389787

37606281 GetRecv() missed block? Sequence 1401128 jumped to 1401142

37607757 GetRecv() missed block? Sequence 1401203 jumped to 1401216

37608697 GetRecv() missed block? Sequence 1401284 jumped to 1401296

That's all pretty horrible. The data failures are almost certainly going to be some problem with the applications, somehow. The "missed blocks" at the end may be related to close down actions.

Tracking back to see what's changed is needed I fear.

Regards,

Pete

Link to comment
Share on other sites

Good morning Pete,

Boy, I get faster replies from you than I do from my kids and they are in the next room! ;-) Nothing has changed other than updating PM software, WideFS, and FSUIPC when they are available. I run the two modules because one is needed to run the GF RP48 (GFPM Remote) and the other to run the GF-MCP. Neither will do both. The GFRemote is more critical because I could always run the GF48 on the main computer complements of FSUIPC but I don't think the MCP will work that way. Thanks for giving this some thought!

David

Link to comment
Share on other sites

Nothing has changed other than updating PM software, WideFS, and FSUIPC when they are available. I run the two modules because one is needed to run the GF RP48 (GFPM Remote) and the other to run the GF-MCP. Neither will do both.

Hmmm. Well it looks like something is conflicting with something else. Unfortunately when there's so many programs competing for WideClient's attention it is difficult ot find out which is actually responsible for those invalid requests. It sounds like it is the GF program you mentioned, but it may be that it induces a confluict somewhere.

Why not try programming the RP48 through FSUIPC and remove that application, see if that helps? The currently released WideClient does support GoFlight buttons -- if you've installed the GF drivers on that PC, FSUIPC on the FS PC should recognise all the buttons and dials. Please see the FSUIPC dox.

Regards,

Pete

Link to comment
Share on other sites

196 Trying TCP/IP host "Delxp" ...

2033323 READSTATEDATA received with bad data size!

2033323 851 ReadLocal: Offset=786C6564, Size=5C70

I just noticed that the bad data read here is actually part of the control area of the READ command (in the FSUIPC request protocol) corrupted by ASCII characters:

Offset=786C6564 is 64 65 6C 78 which is "delx"

and

Size=5C70 is 70 5C which is "p".

It looks very much like something involving the name of the path of something on your FS PC (the Server) is getting written into the data area which should be reserved for the FSUIPC interface operation. Your server is named "delxp" and a path to something on it would be \\delxp\ ...

This is something of a clue, but not enough to positively identify the module in error. Maybe one of them is reading a path FROM FSUIPC and is not allowing enough memory. Or else one of them is not using the library code I provide and doesn't check the memory allocation so thoroughly.

We may be able to identify the errant program by increasing the logging in WideClient, though even then I'm not sure it keeps track of who's who when obeying requests. Try "Log=DebugAll" -- but, beware, the log will be BIG and very difficult to analyse. If you want me to look, ZIP it and send it to petedowson@btconnect.com.

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.