Hi Steve,
Thanks for sharing your further test results. The iterative self-tuning
procedure seems to work very well, and guess we are agreed that
stochastic substitution of second-best symbols isn't buying us enough to
make the performance hit worthwhile. We should, however, remain
open-minded about a possible advantage in conditions of Rayleigh fading,
QRM, etc.
I also observed the smaller number of decodes when sfrsd2 is invoked
from within WSJT-X, compared with WSJT. I haven't tracked down the
reason, yet; I still suspect that some upstream filter is rejecting some
signals that are actually worthy of attention. At HF we were not so
hungry for the last 0.5 dB of sensitivity.
Your notion to do multi-threading by running multiple simultaneous sfrsd
threads may indeed be a good way to go. As you say, the setup time in
sfrsd (before entering the stochastic loop) is small enough to be
ignored. Moreover, that makes it easy to use OpenMP because we can do
that part in Fortran -- similar to how it's done in already when doing
both JT9 and JT65 at the same time. Nothing special needs to be done to
the sfrsd code; there's no need for it to be C++ rather than C. We will
just need to take care to distinguish shared variables from "per thread"
variables, do I/O in the main thread, etc. I managed to make this work,
before, and Bill knows all the tricks.
-- Joe
On 9/30/2015 8:25 PM, Steven Franke wrote:
> Joe,
>
> 1. This summarizes decoding results using exp(x) (aka “jt”) symbol metrics
> and power-percentage (aka “sf”) symbol metrics.
>
> The procedure in each case was to self-tune the algorithm by (i) running with
> an arbitrary erasure probability matrix and then (ii) using probability of
> symbol-error and probability of correct-mr2 in fort.40 to update the erasure
> and insertion probability matrices. I iterated this procedure until it
> converged (2 or 3 runs). After tuning, the algorithm was run with the mr2
> insertion probability scaling factor set to 0.0 (no mr2syms) and again with
> the scaling factor set to 0.3 (does some mr2sym insertions). For the latter
> case, it is necessary to set the calc_syn parameter to 1 in the call to
> decode_rs.
>
> sf metrics with no mrsyms (mrsym 0.0):
> 1. 835 with ntrials=10000
> 2. 733 with ntrials=1000
> 3. 502 with ntrials=100
>
> sf metrics with mrsyms (0.3):
> 1. 839 with ntrials=10000
> 2. 747 with ntrials=1000
> 3. 556 with ntrials=100
>
> jt metrics no mrsyms (0.0):
> 1. 836 with ntrials=10000
> 2. 733 with ntrials=1000
> 3. 533 with ntrials=100
>
> jt metrics with mrsyms (0.3):
> 1. 837 with ntrials=10000
> 2. 745 with ntrials=1000
> 3. 560 with ntrials=100
>
> Conclusions:
> - no significant differences between sf and jt symbol metrics, provided that
> proper erasure/mr2-insertion probabilities are used.
> - The mr2sym insertion does improve results significantly at very small
> ntrial values, but see item 2., below.
>
> 2. I did some execution time runs and I can verify your assertion that
> setting calc_syn=1 in the call to decode_rs (which is necessary when mr2sym
> insertion is done) increases execution time by a factor of approximately 1.6.
> Which is why the option to turn off the syndrome calculation was put in.
> Thus, the conclusion here is that the added overhead necessary to do mrsym
> insertion is not worth it, at least for the idealized no-fading simulated
> signals analyzed in these tests.
>
> It’s striking that the results of all 4 experiments are essentially the same
> at ntrials=10000. This suggests to me that we are decoding all of the cases
> that are admitted by our nhard/nsoft-based selection criteria. I suppose that
> more work could be done to try to refine these criteria. In fact, I should
> mention that I am having second thoughts about my nsoft metric. I can’t help
> thinking that it should be based on log(p1) instead of p1 - so I may come
> back to that eventually. Before that, I think that I’d like to see what
> happens to the erasure probabilities if we tune on some real data.
>
> Finally, I am able to compile and run WSJT-X r5950 on OS X. Seems to work
> fine, although I only got 448 decodes. Perhaps this is due to the mismatched
> metrics. I’ll play around with it.
>
> Steve k9an
> ------------------------------------------------------------------------------
> _______________________________________________
> wsjt-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
