Hi Steve,

Yes, 40 iterations for bp.

With norder=2 hardwired for everything I still get 574 good decodes. So at least in jt9.exe, with no attempt to move nfqso around, using norder=3 produces no more decodes.

Here are the timer results with norder=2:

 Name                 Time  Frac     dTime dFrac    Calls
----------------------------------------------------------
 jt9                33.832  1.00     0.691  0.02        1
  read_wav           0.164  0.00     0.164  0.00    27404
  decft8            32.977  0.97     0.055  0.00      527
   sync8             4.148  0.12     4.148  0.12      527
   ft8b             28.773  0.85     0.090  0.00     2821
    bpd174           1.641  0.05     1.641  0.05     2821
    osd174          27.043  0.80    27.043  0.80     2210
----------------------------------------------------------
                                    33.832  1.00

        -- Joe

On 6/30/2017 10:34 AM, Steven Franke wrote:
Joe,
Were these results obtained with 40 iterations for bp and norder = 3 for 
signals at or within 10 Hz of nfqso? If so, it might be interesting to see how 
the numbers would change if you dropped back to norder=2 for all signals.
Steve

On Jun 30, 2017, at 9:25 AM, Joe Taylor <j...@princeton.edu> wrote:

Hi all,

Thanks for a busy ~20 hours of many people testing FT8.  I now have accumulated 
a directory with 527 *.wav files, each of which has at least one visible FT8 
signal.  The files were recorded at K1JT at either 14.079 or 50.313 MHz.

Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this collection of 
files produces 574 valid decodes and 0 false decodes with total execution time 
39.8 s.  The average time to process a 15 s Rx sequence on this machine (Core 
i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not bad!

Here's the detailed execution-time breakdown from timer.out:

Name                 Time  Frac     dTime dFrac    Calls
----------------------------------------------------------
jt9                39.828  1.00     0.734  0.02        1
  read_wav           0.121  0.00     0.121  0.00    27404
  decft8            38.973  0.98     0.133  0.00      527
   sync8             4.191  0.11     4.191  0.11      527
   ft8b             34.648  0.87     0.051  0.00     2821
    bpd174           1.480  0.04     1.480  0.04     2821
    osd174          33.117  0.83    33.117  0.83     2210
----------------------------------------------------------
                                    39.828  1.00

Note that 83% of the execution time is spent in routine osd174, 11% in sync8, 
and 4% in bpd174 (a contraction for subroutine name bpdecode174).

It turns out that only 14 of the 574 decodes were produced by osd174, the "ordered 
statistics" decoder.  The rest came from bpd174.  With osd174 deactivated, timer.out 
looks like this:

Name                 Time  Frac     dTime dFrac    Calls
----------------------------------------------------------
jt9                 6.641  1.00     0.891  0.13        1
  read_wav           0.168  0.03     0.168  0.03    27404
  decft8             5.582  0.84     0.094  0.01      527
   sync8             3.887  0.59     3.887  0.59      527
   ft8b              1.602  0.24     0.109  0.02     2821
    bpd174           1.492  0.22     1.492  0.22     2821
    osd174           0.000  0.00     0.000  0.00     2210
----------------------------------------------------------
                                     6.641  1.00

Now the average execution time for a 15 s Rx sequence is just 13 ms!

We need to keep decoding time very short -- say, well under 1 s -- so that 
auto-sequencing, if not the human operator, can select proper responses to received 
messages.  Fortunately, we already have good baseline performance -- and we have a number 
of "knobs" to play with.

        -- Joe, K1JT

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to