All, Since Joe mentioned revision 7754, I unofficially built it for OSX 10.9+ and uploaded it here: https://drive.google.com/open?id=0B4DphHV_ItCZbjZDdmt2NnR2cHc
If you're a macOS user, I'll try to keep recent builds in the same directory (if that's ok w/ Joe, et al, re: unofficial builds). -- David Tiller Sr. Architect/Lead Consultant | CapTech (804) 304-0638 | dtil...@captechconsulting.com On Jun 30, 2017, at 10:45 AM, Joe Taylor <j...@princeton.edu> wrote: > 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 ------------------------------------------------------------------------------ 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
