Hi Steve – Sorry it has taken a few days to answer your questions, and think I have now figured out how to edit e-mails and the subject line when responding on this forum … not new to WSJT-X, but new to formatting responses on this forum.
As a reminder, this is on a RigPi (3B+) connected via USB to a FT-991 working FT-8. On the RigPi, my typical DT values for transmissions that I think have well set clocks are 0.0 to 0.3. I see this using 2.1.2 and 2.2.1. This seems pretty steady for lots of decodes on a busy band or light bands. On 2.2.1, I see just a very few decodes in the first decode pass of the cycle, a quick flash on the decode button on the second (which makes sense from what was described in this thread as happening in that cycle) and then very many in a long, third pass that runs well into the next cycle. All of this is seen in the FAST decode mode on 2.2.1. On 2.1.2, in the FAST decode setting, I get many decodes which are complete by a second or two into the next cycle. I did go back and look at the RigPi behavior on 2.1.2 on NORMAL and DEEP. The RigPi does take a fair amount of time to decode a busy band into the next cycle for those settings, but as mentioned, it works just fine using FAST. So I understand the compute resource issue with the RigPi, and know it is not as good a device for NORMAL or DEEP as then FT8 bands have become more crowded. What I don’t understand is why with FAST the 2.2.1 decoder has slowed so much. I have also set-up 2.2.1 on a Mac-Mini … older, but a lot more robust than a RigPi. That system decodes in FAST, NORMAL, and DEEP with a performance I would expect (2.4 Ghz Intel, cached HD). As you probably already know, the RigPi is something like a 1.4Ghz ARM. So I know a hardware upgrade will fix my issue, but still wondering what happened to FAST decode that used to work on the RigPi. ’73 - Tony ---- Prior message in thread --- Message: 2 Date: Tue, 9 Jun 2020 08:39:08 -0500 From: Steven Franke <[email protected]> To: WSJT software development <[email protected]> Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 76, Issue 93 Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Hi Tony, > Using a 2.2.x version, decoding on a busy band has the following behavior: > first decode in cycle picks up a few messages, second decode a few, then the > third decode runs a long time (well into the next cycle) and the majority of > messages get decoded on that third decode. What are your typical DT values, i.e. what is the median DT value for a cycle that has a good number of decodes? Normally, we expect to see the bulk of the decodes produced by the first decoding segment (say, 80%) and only a small number of decodes produced during the third segment. However, if there is significant receiver latency, this can push most of the decodes into the third segment. FWIW, no decoding is done during the second decode segment. This segment is used to subtract all of the decodes that were obtained during the first segment. Steve k9an
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
