Yep...same context# on all 3. Here's what I think now that might explain why sometimes it works and sometimes not. It does appear that HRD spawns a thread for each client. But is the underlying select giving first-come-first-serve priority? It sure looks like it. So when you start HRD, then Logbook, then WSJT-X, Logbook gets priority as the first socket in the select. If you start HRD, then WSJT-X, then HRD, then WSJT-X gets priority. That would explain why I ran for 6 hours without much problem and why I couldn't duplicate the problem for a while yesterday. But restarting HRD (or maybe just disconnect all clients) is needed to reset the sockets so WSJT-X can get priority. Since WSJT-X doesn't stack commands it never starves Logger and even if Logger does stack commands WSJT-X gets first priority so no problem (at least no huge delays). I'm also thinking when you request frequencies HRD asks the radio instead of returning what's in memory already which might explain the 2 second response time in the serial code when commands get stacked (doing a sleep somewhere perhaps?).
It might be handy in the debug to have a time-to-run-command value that you could grep and plot to see the distribution of response times. Then run the apps in the different sequences and see how they behave statistically. I may do that and see if that helps prove my point. Hopefully HRD will acknowledge the problem since it really appears to be in their court now. Mike W9MDB -----Original Message----- From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Tuesday, September 09, 2014 8:06 AM To: WSJT software development Subject: Re: [wsjt-devel] HRD tcp bug On 09/09/2014 13:48, Michael Black wrote: Hi Mike, > I've determined the problem now is with HRD (running 6.2.72.293) and Windows > 7 32-bit. So I'm going to report this to HRD. This behavior also shows > up during WSJT-X operations during frequency changes with very slow > freq changes (like 10 seconds for example). This is WSJT-X v1.4.0 r4270-dirty. > Now that the send cmd is time-synced with the network traffic in my > patch this is easier to correlate. I still have the 30 second timeout > too at this point since that makes it easier to see what's happening right now. > Here is a very clear example. AT 18:20:13 WSJT-X sends "get frequencies" > (note that the send message doesn't show up until AFTER the reply is > received in this trace log). After the ACK from HRD for that packet > HRD does not send the answer or any other packet for another 11 > seconds at 18:24. > Meanwhile HRD Logger is happily chatting with HRD. What's of interest > and may explain why this sometimes works and sometimes not is that in > this example HRD Logger asks for frequencies, HRD acks, then WSJT-X > asks for frequencies before HRD replies to Logger. So this interplay > may be what causes the problem. I notice that HRD has given the same context number to HRD Logbook and to WSJT-X for your rig. I wonder if that is the real problem, maybe it is not creating a unique context for each client and therefore not able to deal with them independently internally. The context number is issued by HRD when a client sends the "get context" command and the number returned has to be prepended in brackets to every command to that rig. The number is also listed against each rig in the "get radios" command response. All this is guesses since it is all undocumented :( It is of course possible that the context number is only unique to a rig connection and the HRD internals are supposed to differentiate clients by the socket they connect on. So here's a question: When both HRD Logbook and DM780 are chatting with HRD, do they use the same context number? 73 Bill G4WJS. ---------------------------------------------------------------------------- -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
