Locked Important: How quickly can it complete the decoding process?

Nc8q-mesh@gelm.net <nc8q-mesh@...>

On 2/19/20 5:11 AM, Bill Somerville wrote:


there's no surprise here and nothing particularly useful either other than the 2 second metric. The FT8 decoder will spread a small amount of its load across CPU threads when doing FFTs but the bulk of the decoding is computed on a single CPU thread and is unrestricted so will always use 100% CPU resource on the logical CPU thread it is running on, unless it is interrupted by another process.

What is important is how quickly it can complete the decoding process, not how much CPU resource, measured as a percentage, is indicated.

Hi, Bill:

 Thanks. I think this needs its own thread. :-|

What is not quoted here was a nice review, but what caught my attention was the quoted part above.
"What is important is how quickly it can complete the decoding process".
Yeah, that!
How do I measure that?

 While participating in that query on the RPi4 in 'DEEP' decode issue,
I noticed that, while calling another station (or was I calling CQ, anyway)
after my station began transmitting there a few more decodes appearing in the 'Band Activity' pane.
So, those 'deep decodes' were not considered by the time my station was ready to transmit.

 However, would it be a benefit to 'deep decode' a few cycles, then 'Enable AP' decode
to work that weak signal?



Join {main@WSJTX.groups.io to automatically receive all group messages.