David Lee Posted July 24, 2004 Report Posted July 24, 2004 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
Pete Dowson Posted July 24, 2004 Report Posted July 24, 2004 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
David Lee Posted July 25, 2004 Author Report Posted July 25, 2004 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
Pete Dowson Posted July 25, 2004 Report Posted July 25, 2004 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
David Lee Posted July 25, 2004 Author Report Posted July 25, 2004 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
Pete Dowson Posted July 25, 2004 Report Posted July 25, 2004 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
Pete Dowson Posted July 26, 2004 Report Posted July 26, 2004 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
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now